数据库结构和源代码控制 - 最佳实践

Question

背景

我在一家公司工作了几年,所有数据库对象都存储在源代码管理中,每个对象一个文件.我们有一个列表,列出了添加新项目时维护的所有对象(允许我们按顺序运行脚本并处理依赖项)和一个运行创建一个大脚本以运行数据库的VB脚本.

所有的表都是"如果不存在则创建",并且所有SP等都被删除并重新创建.

到目前为止,我现在在数据库是主数据库的地方工作,并且没有数据库对象的源代码控制,但是我们使用redgate的工具来更新我们的生产数据库(SQL比较),这非常方便,并且需要很少的工作.

题

你如何处理你的数据库对象？我喜欢将它们置于源代码控制之下(并且,因为我们正在使用GIT,我希望能够处理脚本中的合并冲突,而不是数据库),但是我会被迫过去使用SQL比较的简易性来更新数据库.

我真的不想让我们在GIT中更新脚本,然后使用SQL compare从DEV DB更新生产数据库,因为我宁愿拥有'一个版本的事实',但我真的不想重新编写一个自定义的软件,将大量脚本捆绑在一起.

我认为视觉工作室数据库版本可能会做类似的事情,但我不确定我们是否会有预算.

我确信这已经被要求死亡,但我找不到任何似乎有我想要的答案的东西.与此类似,但不完全相同:

代码控制下的数据库脚本的最佳实践是什么？

---

开始赏金,因为我有兴趣拉票以获得更多意见 - 这里的答案是合理的,但我觉得应该有一个更简单的方法.

感谢所有伟大的答案 - 都有他们的优点,所以我将采取最高票,但欢呼所有的投入.

Answer 1

看看这个关于数据库版本控制的原理和实践的五部分系列(由K. Scott Allen撰写):

1. 数据库工作的三条规则
2. 基线
3. 更改脚本
4. 视图,存储过程等
5. 分支和合并

这五个部分很重要,但基本上我们的想法是拥有一个基线,然后更改脚本(使用版本表).更新数据库意味着在当前版本"上方"应用更改脚本.而且这种策略非常适合VCS(没有冲突).

Answer 2

我们使用Visual Studio Database Edition(DBPro)在源代码管理下拥有所有数据库对象.它是一个很棒的工具,版本控制我们的架构,构建,验证,允许代码分析,架构比较,部署,数据比较,重构等.它是从头开始设计的数据库管理和版本控制系统.强烈推荐.

这是DBPro首席架构师的博客站点: 点击此处

Answer 3

使用第三方SSMS加载项ApexSQL源代码控制,如果您更喜欢使用本地存储库,则可以自动编写数据库对象并将其推送到远程Git存储库,甚至推送到克隆的本地存储库.

ApexSQL Source Control支持开箱即用的Git源控制系统.这意味着您不需要安装任何其他Git客户端.除此之外,分支和合并是通过加载项UI集成和提供的.