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