在Web应用程序中,如何使数据库结构保持最新?

就我个人而言,我使用一个非常类似于你所列出的过程,我可以看到你关于改变的论点,但我很少做改变,然后在一个生产站点上改变它回到原来的方式。在测试中,是的,确实如此,但就实际的生产站点而言,我不认为这有什么大不了的。

保持单个版本脚本,imho不仅有利于部署,而且有利于提供可以签入源代码管理的项。

许多框架使用“迁移”的概念——将数据库模式从一个版本升级到下一个更高版本的脚本。同样,降级脚本通常也很有用,以防您需要退出更改。有时这些脚本是SQL中的,有时是抽象的(例如RubyonRails)。您可以手工设计这些脚本,或者使用其他人提到的类似SQL比较的工具。

在数据库中创建一个只有一列一行的表来指示模式修订也很有帮助。一些支持迁移的框架依赖于此了解应用哪些迁移脚本来升级或降级架构。

您的应用程序应该有一套可以运行以验证应用程序功能的测试。您还可以向这个套件中添加功能测试,以检查模式并确认预期的表、列、过程等存在。当你修改项目时,修改测试。正如在源代码管理中必须跟踪应用程序功能的测试以及它们测试的代码一样,架构结构的测试也必须跟踪。

最后,数据库设计为应用程序的设计奠定了基础。在部署之前,适当的软件工程应该会产生相对稳定的数据库模式。对数据库模式的后续更改既应该很小,也应该很少。

首先,我们引入了一个版本表——跟踪应用程序版本号的模式,并跟踪每个被邀请表的版本号。我们有一个模式版本,我们硬编码到应用程序中以对照这个应用程序版本进行检查。我们不希望应用程序访问错误版本的数据库。然后,我们为每个从上一个表版本迁移到当前版本的表提供了一组脚本。然后,我们在应用程序中嵌入了一个目标表,以了解新版本中每个表的版本,以查看是否匹配所有内容。如果没有,我们将各种迁移脚本应用到模式中,以使数据库正常运行。

复杂的?有点。救命。异常地没有什么比在应用程序中追逐错误更重要的了,因为模式是错误的。

您应该研究一个叫做PowerDesigner的工具。您可以下载一个15天的完全可操作的试用版。它将帮助您建立模型,保持最新的更改等。

这是一个很好的工具,可以做你想要做的事情,还有更多。

我们在版本控制存储库中为每个版本创建一个目录。我们编写了一个脚本,它读取该文件夹中的脚本,并按文件名顺序运行它们(因此我们编写的脚本的名称如32.0.0_AddColumnXXXYYY)。这种点格式允许我们根据需要在序列中插入脚本。

当我们更新一个站点时,会检测并运行新的脚本。这比像SQL比较(我非常喜欢)这样的工具有一个优势,因为我们可以一次性修改数据。但是,我们确实运行了SQL比较和SQL数据比较(在选定的表上) 之后 确保程序正常运行的更新。成功运行后,将提交整个操作,数据库将更新“运行脚本”信息,以便不再运行这些脚本。

这样做的好处是我们不能“忘记”一个脚本。此外,当我们尝试滚动到测试或登台数据库时,我们经常会发现备用数据集在到达生产之前就已经找到了隐藏的假设。

它的另一个优点是,我们可以为不同的客户将不同的安装保持在不同的功能级别,但是当我们进行升级时,所有脚本都已就位并可以运行。我在这个方案中遇到的唯一问题是一个“无序”的补丁正在应用于用户的数据库…您必须编写脚本以检测原始状态 如期 如果没有的话就放弃。

你可能应该读一下阿特伍德写在数据库版本控制上的一篇关于恐怖编码的文章: Is Your Database Under Version Control?

使用类似Redgate的SQLCompare或XSQL软件中的XSQL对象这样的工具来动态生成diff/delta T-SQL脚本。

如果您愿意的话,您甚至可以将它集成为构建过程的一部分。

对于具有不同数据库的不同客户,您只需为他们提供不同的参考数据库,并与之进行比较。一旦向客户发布更新,就可以使用相同的diff脚本更新自己的参考站点。

简而言之就是这样。

我和你做的差不多。我保存了一个数据库发行说明文件,其中包含我最近的所有更改,并在顶部列出了Subversion修订号。它还包含为应用此更改而运行的SQL。

并行地,我维护一个数据库模型(我使用 Azzurri Clay 在Eclipse中),以便我可以随时重新生成我的模型。如果需要进行任何更改,我首先在模型中进行更改,然后更新我的发行说明。尽管只有创造,但azzurri无法产生变化。

这些都存储在Subversion下,以便在需要时回滚。我可能应该在我的应用程序的SVN版本和我的模型的版本之间保持某种联系。