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 回答