在开发过程中保持SQL Server数据库项目和实际数据库(在SSMS中)同步

3
我正在尝试弄清楚SQL Server数据库项目和实际数据库(SSMS)之间的正常工作流程一旦它们同步。我使用这些项目的主要原因是为了将所有内容保存在源代码控制中。
以下是我设置事物的步骤:
1. 在SQL Server Management Studio中创建实际数据库和整个模式。 2. 在VS2015中创建一个新的SQL Server数据库项目。 3. 右键单击该项目并导入实际数据库。
现在,项目已与实际数据库同步,那么我应该如何进行以后的更改?我是在数据库项目中进行更改然后重新发布呢,还是在模式中进行更改?基本上,我的意思是我正在尝试避免在两个地方都进行开发期间的模式更改。
1个回答

3
通常最佳实践是对项目进行更改,将其检入源代码控制,并根据需要发布更改到您的数据库。然后您的项目就成为了源代码。您可以将其分支、合并和执行其他任何必要的开发工作。虽然您不会重新发布您的数据库,但在发布您的项目时,您将更新现有的数据库。它将在项目和数据库之间执行差异,然后进行适当的更新/更改,使您的数据库与项目保持一致。
我在这里记录了我使用SSDT的经验: http://schottsql.blogspot.com/search/label/SSDT ,但如果您搜索,还有其他很棒的资源可用。肯定有不同的做事方式,而我选择的方式可能并不完全适合您的环境。

有趣的是,在我们在Redgate进行的数据库项目用户调查中,我们了解到大多数用户首先对其开发数据库进行更改,而不是离线更改。我猜这是因为等待F5构建会有一些额外的开销。 - David Atkinson
好的,我会先对数据库进行更改,但 SQL Source Control 给我的一个困扰是我感觉需要先将我的数据库与当前分支保持一致,然后再进行更改。我会在本地进行更改(Intellisense 有帮助),但很快将脚本复制到 SSDT 中。对于表格,我通常会先使用 ER Studio,得到模型的认可,然后添加到源代码控制中。然而,推送到共享环境都来自于那个 SSDT 项目。其余的只是临时工作。 - Peter Schott
你尝试过ReadyRoll吗?它支持在Visual Studio中进行连接开发,从而避免了“复制脚本”步骤的开销。 - David Atkinson
我还没有尝试过那个。虽然我不太担心连接开发部分。很多时候,当我在玩本地实例时,我会在最终确定之前先思考一些想法。特别是对于存储过程/视图,我会经历许多迭代,因为我正在解决不同的行为、性能等问题。不过,我会看一下这个项目它是做什么的。 :) - Peter Schott
没错。ReadyRoll通过以不同的方式处理“可编程对象”来识别它。我认为你会喜欢它的。http://doc.ready-roll.com/display/RRSQLDOC/Programmable+Objects - David Atkinson

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接