我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。

令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。

不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。

在这方面有什么最佳实践吗?你有哪些行之有效的策略?


当前回答

是的……我们的数据库是在ERwin中设计的,每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上,我们的工程文档也是如此)。

其他回答

数据库本身?没有

创建它们的脚本,包括静态数据插入、存储过程等;当然可以。它们是文本文件,它们包含在项目中,像其他东西一样签入和签出。

当然,在理想情况下,您的数据库管理工具可以做到这一点;但你必须遵守纪律。

我通过保存创建/更新脚本和生成sampledata的脚本来完成。

The most successful scheme I've ever used on a project has combined backups and differential SQL files. Basically we would take a backup of our db after every release and do an SQL dump so that we could create a blank schema from scratch if we needed to as well. Then anytime you needed to make a change to the DB you would add an alter scrip to the sql directory under version control. We would always prefix a sequence number or date to the file name so the first change would be something like 01_add_created_on_column.sql, and the next script would be 02_added_customers_index. Our CI machine would check for these and run them sequentially on a fresh copy of the db that had been restored from the backup.

我们还准备了一些脚本,开发人员可以用一个命令将本地db重新初始化到当前版本。

我使用ActiveRecord Migrations。这个Ruby gem可以在Rails项目之外使用,并且有适配器可以处理您遇到的大多数数据库。我的建议:如果你能够在Postgres上运行你的项目,你就会得到事务性的模式迁移。这意味着如果迁移只应用了一半,您不会最终得到一个损坏的数据库。

我通过编写脚本输出所有对象(表定义、索引、存储过程等)来源控制数据库模式。但是,至于数据本身,只需依赖定期备份。这确保了所有的结构更改都被正确的修订历史记录捕获,但不会在每次数据更改时给数据库带来负担。