作为一名数据库架构师、开发人员和顾问，有很多问题可以回答。其一，虽然最近被问到，还是答不上来，是……
“在单开发人员或多开发人员环境中保持数据库更改记录、组织并能够有效推出的最佳方法或技术之一或部分是什么。”
这可能涉及存储过程和其他对象脚本，但尤其是模式 - 从文档到新的物理更新脚本，再到推出，然后是完整的循环。有一些应用程序可以实现这一点，但需要模式挂钩和开销。我更想了解在没有大量额外第三方参与的情况下使用的技术。
【问题讨论】：
标签： sql database architecture schema methodology
如果你愿意的话，我见过的最简单的方法是创建一个“模式补丁”。架构补丁只是一个简单的 t-sql 脚本。架构补丁在脚本中被赋予了一个版本号，并且该版本号存储在数据库的表中以接收更改。
对数据库的任何新更改都涉及创建一个新的架构补丁，然后您可以按顺序运行该补丁，然后检测数据库当前的版本并运行其间的所有架构补丁。之后，模式版本表会更新为执行补丁以存储下一次运行的任何日期/时间。
一本详细介绍此类细节的好书叫做Refactoring Databases。
如果您想使用外部工具，您可以查看Ruby's Migrations 项目或 C# 中称为Migrator.NET 的类似工具。这些工具通过创建具有“前向”和“后向”迁移的 c# 类/ruby 类来工作。这些工具功能更丰富，因为它们知道如何在模式补丁中前进和后退。然而，正如您所说，您对外部工具不感兴趣，但我想我还是会为其他读者添加它。
【讨论】：
【讨论】：
在我的情况下，每次更改数据库时都会生成一个脚本，我将脚本命名为 00001.sql、n.sql，并且我有一个表，其中包含我执行的最后一个脚本的编号。也可以看Database Documentation
【讨论】：
只要您将列/表添加到数据库中，通过提前在 sql 文件中编写这些更改的脚本，这将是一项简单的任务。你只需执行它们。也许你有一些命令来执行它们。
一个好的解决方案是为每个表创建一个文件，这样所有在表上工作的人都可以看到属于该表的所有更改（就像在上课一样）。这同样适用于存储过程或视图。
一个更困难的任务（因此也许工具会很好）是退后一步。只要您只是添加表格/列，这可能不是一个大问题。但是，如果您在更新中删除了列，现在您必须撤消更新，则数据不再存在。您将需要从备份中获取此数据。但请记住，如果您有更多的表，这可能是一项艰巨的任务，在正常情况下，您应该非常快速地撤消更新！
如果您可以恢复备份，那么此时就可以了。但是，如果您在周一更新，您的客户一直工作到周三，然后他们发现某些数据丢失（您刚刚从表中删除），那么您就不能只恢复旧数据库。
我有一个基于模型的方法（抱歉，目前没有实现），其中模式更改被“建模”（例如每个 xml），并且在更新期间处理器（例如 ac# 程序）创建所有必要的“sql”，例如将数据移动到“dropDatabase”。数据可以驻留在那里，如果由于某种原因我需要恢复一些丢失的数据，我可以用处理器来完成。我认为在一段时间（几年）内，这种方法并没有那么糟糕，因为否则开发人员不会接触“旧”表，因为他们不再知道表或列是否真的需要。使用这种方法，您不会因为丢东西而冒太大风险！
【讨论】：
我做的是：
诀窍在于，如果数据库无法通过添加列重新创建，我需要进行 两个 更改，即 ALTER TABLE + 脚本中的修改。多做一些工作，但从长远来看，它会赢。
【讨论】：