在Web应用程序中，如何使数据库结构保持最新？
https://stackoverflow.com/questions/240886
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
如果在部署应用程序后数据发生变化，您如何使数据库保持最新状态？
我的意思是，您可以添加或删除表，这是一项简单的任务。改变现有的表也很简单。但是如果你经常改变结构，你如何控制它呢？
我曾经在数据库中保留一个包含当前数据库版本的表。然后每次升级都是一个完成其工作的SQL文件 - 创建新表，添加列或移动数据。文件是以这些版本命名的 - 所以如果我的升级脚本获得了数据库版本10，它只是将所有文件从11.sql转换为N.sql并同时应用它们中的每一个递增数据库版本号。
这似乎工作正常，但我想知道 - 你有什么策略来完成这些任务？
如果我在一个“补丁”中对一个表进行规范化，那么这个系统似乎并不完美。之后，无论出于何种原因，我再次将其归一化。然后它完成了两次。
但是，每次更改内容时编写完整的升级脚本都会让人感到痛苦，而且容易出错。至少还有这种原子变化。
此外，我可以预期不同的客户可以随时运行不同的数据库版本，所以我真的应该有办法从任何一点上升。
解决方案
我个人使用与你列出的内容非常相似的过程，我可以看到你关于改变的论点，但我很少做出改变，然后在生产站点上将其改回旧的方式。在测试中，是的，这种情况发生了，但就实际生产网站而言，我认为这不是什么大问题。
保留个人版本脚本，恕我直言不仅有利于部署，而且还有助于提供可以检入源代码控制的项目。
其他提示
许多框架使用“迁移”的概念。 - 将数据库模式从一个修订升级到下一个更高版本的脚本。同样，降级脚本通常也很有用，以防您需要退出更改。有时这些脚本在SQL中，有时它们是抽象的（例如Ruby on Rails）。您可以手动设计这些脚本，也可以使用其他人提到过的SQL Compare等工具。
在数据库中创建一个包含一列一行的表也很有帮助，以指示架构修订。一些支持迁移的框架依赖于此来了解要应用哪些迁移脚本来升级或降级架构。
您的应用程序应该有一套可以运行的测试来验证应用程序功能。您还可以向此套件添加功能测试，以检查架构并确认存在预期的表，列，过程等。在修改项目时，请修改测试。正如必须在源代码管理中跟踪应用程序功能的测试以及它们测试的代码一样，也必须跟踪架构结构的测试。
最后，数据库设计构成了应用程序设计的基础。在部署之前，正确的软件工程应该会产生相对稳定的数据库模式。对数据库模式的后续更改应该既小又不频繁。
首先，我们引入了一个版本表，该模式跟踪了为其设置架构的应用程序的版本号，并跟踪每个invidual表的版本。我们有一个模式版本，我们硬编码到应用程序中以检查此应用程序版本。我们不希望应用程序访问错误的DB版本。然后，我们为每个表创建一组脚本，从先前的表版本迁移到当前版本。然后我们有一个目标表，我们将其嵌入到应用程序中，以了解新版本中每个表的版本，以确定我们是否匹配所有内容。如果没有，我们将各种迁移脚本应用于模式以使数据库达到鼻烟。
复杂？有些。拯救生命。 abosolutely。没有像在应用程序中追逐错误，因为架构是错误的。
你应该研究一个名为Powerdesigner的工具。您可以下载为期15天的全面运营试用版。它将帮助您建模，更新最新等等。
这是一个很好的工具，可以满足您的需求，也可以提供更多。
我们在版本控制存储库中为每个版本创建一个目录。我们编写了一个脚本来读取该文件夹中的脚本并按文件名顺序运行它们（因此我们编写名称为32.0.0_AddColumnXxxxYyyy的脚本）。这种虚线格式允许我们根据需要将脚本插入序列中。
当我们更新站点时，会检测并运行新脚本。这比SQL Compare（我非常喜欢）这样的工具有优势，因为我们可以对数据进行一次修改。但是，我们会在更新后运行SQL Compare和SQL Data Compare（在选定的表上），以确保该过程正常运行。在成功运行之后，提交整个操作并且数据库更新“运行脚本”。信息，因此这些脚本不会再次运行。
这样做的好处是我们不能“忘记”一个脚本。此外，当我们尝试滚动到测试或临时数据库时，我们经常发现隐藏的假设，即备用数据集在生产之前就会发现。
另一个优势是我们可以为不同的客户保持不同功能级别的各种安装，但是当我们进行升级时，所有脚本都已就绪并准备好运行。我对这个方案唯一的问题是“乱序”。修补程序应用于用户的数据库...您必须编写脚本以检测原始状态按预期并且如果没有则中止。
你应该读一下Atwood写的有关编码恐怖的数据库版本控制的文章：您的数据库是否受版本控制？
使用RedGate的SQLCompare工具或xSQL软件的xSQL对象即时生成diff / delta T-SQL脚本。
如果愿意，您甚至可以将其作为构建过程的一部分进行集成。
对于具有不同数据库的不同客户，您只需为它们比较具有不同的参考数据库。一旦您向客户发布更新，您就可以使用相同的差异脚本更新您自己的参考站点。
简而言之就是这样。
我的做法和你一样。我保留了一个数据库发行说明文件，该文件包含我最近在顶部列出的所有更改以及颠覆版本号。它还包含为应用此更改而运行的SQL。
同时我维护一个数据库模型（我使用 Azzurri Clay Eclipse）这样我就可以随时重新生成我的模型。所需的任何更改，我首先在模型中进行，然后更新我的发行说明。虽然只有CREATEs，但是Azzurri无法生成更改。
这全部存储在subversion下，以便我可以在需要时回滚。我可能应该在我的应用程序的svn版本和我的模型的修订版之间保持某种联系。
