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