小组如何跟踪数据库架构更改？

哪些版本控制方法可帮助团队成员跟踪数据库架构更改？

就在几分钟前，我正在检查以下内容：带有数据库的所有项目中都应该存在一个表，看起来很简单，可以付诸实践，将其检出：

它称为schema_version（或迁移，或其他适合您的方式），其目的是跟踪数据库的结构或数据更改。可能的结构（MySQL中的示例）为：

create table schema_version (
     `when` timestamp not null default CURRENT_TIMESTAMP,
     `key` varchar(256) not null,
     `extra` varchar(256),
     primary key (`key`)
) ENGINE=InnoDB;

插入schema_version（key，extra）值（“ 001”，“模式版本”）；

是否从项目开始时添加此表，还是在将第一个版本部署到暂存服务器或生产服务器之后添加表均由您决定。

每当您需要执行SQL脚本来更改数据库结构或执行数据迁移时，也应该在该表中添加一行。并通过在该脚本的开头或结尾处的插入语句来执行此操作（该脚本已提交到项目的代码存储库）。

…

我认为最好的方法是在构建过程中生成数据库。将所有脚本与其余代码保持在源代码控制中，每个人都应对自己的环境负责。

失败的是，RedGate有一个将源代码控制集成到SSMS和SQL Compare中的工具，对于比较/同步MS SQL Server模式非常有用。Visual Studio Database Edition还具有内置的架构比较工具。

另一个SO问题将我引向Migrator Dot Net，我将在我的大量空闲时间开始进行调查。看来这是一种好方法，但可能比您愿意付出的时间/开销更多。

eiefai已经提到了一个表，该表应该存在于所有带有数据库的项目中。这是一篇很棒的博客文章，但IMO仅将其作为一种可行的数据库修订控制解决方案的一部分。我认为在现实世界中“尝试”回答这个问题的任何尝试都需要考虑有关VCS和数据库的其他一些信息：

• 敏捷数据方法
• “数据库重构”书
• 马丁·福勒（Martin Fowler）关于“进化数据库设计”的文章
• Liquibase工具
• 斯科特·安伯勒（Scott Ambler）的一部不错的视频，介绍了他对“敏捷数据库”的看法

我认为，有几个不同的角度来解决这个问题。我认为，“工具优先”的角度将根据平台和个人喜好而有所不同。恰当的例子：我正在MS Visual Studio中使用数据库项目，但是我不确定这是否是MySQL的出色解决方案。我也认识到人们用Redgate，Erwin，Embarcadero等最喜欢的工具卖得很好。

这个问题还有一个“过程优先”的角度，（希望）在此站点上的后续问题中有一个重新讨论的角度。此过程的重点是使模式受源代码控制并管理更改，以便您可以根据需要将模式更改从版本“ x”更改为版本“ y”。

对于该主题的明确答案将最终看起来像一本书，因此可能值得一提，以供参考：Redgate最近出版了一本名为《基于SQL Server团队的Red Gate指南的免费电子书》，国际海事组织（IMO）是一个辩论的好地方。与名称相反，本书中的许多材料都足够通用，可以应用于任何数据库（不仅仅是SQL Server）和任何工具集（不仅仅是Redgate）。如果您还没有看过，至少绝对值得一读。

最后，可能值得链接stackoverflow的“旧式答案”。

SchemaCrawler是我的工具，用于生成包含所有数据库模式对象的文本文件。我将该文本输出设计为易于阅读，并且可与其他服务器的类似输出进行区分。

实际上，我发现在作为构建的一部分完成时，输出数据库模式的文本文件很有用。这样，您可以将文本文件检入源代码控制系统，并拥有有关模式随时间演变的版本历史记录。SchemaCrawler也被设计为从命令行自动执行此操作。