13

作为数据库架构师、开发人员和顾问，有很多问题可以回答。一，虽然我最近被问到，但仍然不能很好地回答，是......

“在单开发人员或多开发人员环境中保持数据库更改记录、组织并能够有效推出的最佳方法或技术之一或部分是什么。”

这可能涉及存储过程和其他对象脚本，但尤其是模式 - 从文档到新的物理更新脚本，再到推出，然后是完整的循环。有一些应用程序可以实现这一点，但需要模式挂钩和开销。我想知道在没有大量额外第三方参与的情况下使用的技术。

4

5 回答 5

4

我更喜欢这个系列： http: //odetocode.com/Blogs/scott/archive/2008/02/03/11746.aspx

于 2009-02-11T00:45:31.937 回答
4

如果你愿意的话，我见过的最简单的方法是创建一个“模式补丁”。模式补丁只是一个简单的 t-sql 脚本。架构补丁在脚本中被赋予了一个版本号，并且该版本号存储在数据库的表中以接收更改。

对数据库的任何新更改都涉及创建一个新的模式补丁，然后您可以按顺序运行该补丁，然后检测数据库当前的版本并运行其间的所有模式补丁。之后，模式版本表将更新为执行补丁以存储下一次运行的任何日期/时间。

一本详细介绍此类细节的好书叫做Refactoring Databases。

如果您希望使用外部工具，您可以查看Ruby 的 Migrations项目或 C# 中称为Migrator.NET的类似工具。这些工具通过创建具有“前向”和“后向”迁移的 c# 类/ruby 类来工作。这些工具功能更丰富，因为它们知道如何在模式补丁中前进和后退。但是，正如您所说，您对外部工具不感兴趣，但我想无论如何我都会为其他读者添加它。

于 2009-02-11T00:47:34.367 回答
1

就我而言，每次更改数据库时都会生成一个脚本，我将脚本命名为 00001.sql、n.sql，并且我有一个表，其中包含我执行的最后一个脚本的编号。您还可以查看数据库文档

于 2009-02-11T00:45:55.993 回答
0

只要您将列/表添加到数据库中，通过提前在 sql 文件中编写这些更改的脚本，这将是一项简单的任务。你只需执行它们。也许你有一些命令来执行它们。

一个好的解决方案是为每个表创建一个文件，这样所有在表上工作的人都可以看到属于该表的所有更改（就像在上课一样）。这同样适用于存储过程或视图。

一个更困难的任务（因此也许工具会很好）是退后一步。只要您只是添加表格/列，这可能不是一个大问题。但是，如果您在更新中删除了列，现在您必须撤消更新，则数据不再存在。您将需要从备份中获取此数据。但请记住，如果您有更多的表，这可能是一项艰巨的任务，在正常情况下，您应该非常快速地撤消更新！

如果您可以恢复备份，那么此时就可以了。但是，如果您在周一更新，您的客户一直工作到周三，然后他们发现一些数据丢失（您刚刚从表中删除），那么您不能只恢复旧数据库。

我有一个基于模型的方法（抱歉，目前没有实现），其中模式更改被“建模”（例如每个 xml），并且在更新期间处理器（例如 ac# 程序）创建所有必要的“sql ”，例如将数据移动到“dropDatabase”。数据可以保存在那里，如果由于某种原因我需要恢复一些丢失的数据，我可以用处理器来完成。我认为经过一段时间（几年），这种方法并没有那么糟糕，因为否则开发人员不会接触“旧”表，因为他们不再知道表或列是否真的需要。用这种方法，如果你丢东西，你不会冒太大的风险！

于 2009-02-11T17:33:50.050 回答
0

我要做的是：

  • 重新创建模式（以及存储过程和索引等）所需的所有 DDL 命令都在脚本中。
  • 为确保脚本正常，不时对其进行测试（创建数据库、运行脚本并恢复备份并检查数据库是否正常工作）。
  • 对于变更控制，脚本保存在版本控制系统中（我通常使用 Subversion）。

诀窍是，如果数据库无法通过添加列重新创建，我需要进行两项更改，一个 ALTER TABLE + 脚本中的修改。更多的工作，但从长远来看，它会赢。

于 2009-02-12T10:11:17.403 回答