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

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

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

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


当前回答

I've heard people say you absolutely have to keep your schemas in the database. I'm not sure I agree. This really depends on the system you're working with. If your system is relatively small and the data is not terribly important. And the the speed at which you need to bring another development environment online is crucial.. then yes.. you can benefit from it. However when your schema is useless without the data and the database is extremely large, it becomes virtually impossible to "source control" your database. Sure, you can still keep your DDL code in source control but that's essentially useless. You can't get the data needed without backup/restore.

在大型数据库开发工作中,我发现备份和恢复是首选的回滚选项。当然,你可以在源代码控制中保留过程、视图、函数等,但要保留表。SQL不是必需的。此外,如果您的部署过程是无懈可击的,那么您很可能永远不需要“回滚”您的生产环境。

其他回答

A big problem, often overlooked, is that for larger web based systems, it is required to have a transitional period or bucket testing approach to making new releases. This makes it essential to have both rollback and a mechanism for supporting both the old and new schema in the same DB. This requires a scaffolding approach (made populist by the Agile DB folks). In this scenario, lack of process in DB source control can be a total disaster. You need old schema scripts, new schema scripts and a set of intermediate scripts, as well as a tidy up, once the system is fully on the new version (or rolled back).

需要的不是从头开始重新创建模式的脚本,而是一种基于状态的方法,在这种方法中,您只需要脚本将DB从一个版本移动到另一个版本,向前或向后移动到所需的状态。您的DB变成了一系列状态脚本,可以轻松地对其进行源代码控制,并与源代码的其余部分一起标记。

我总是检查我的数据库结构转储到源代码控制。全数据库转储,但我通常只是压缩和存储。

我们有一个每周的sql转储到一个颠覆回购。这是完全自动化的,但这是一项非常繁重的任务。

你会想要限制修改的数量,因为它真的会在一段时间后消耗磁盘空间!

任何数据库接口代码都应该进入版本控制(存储过程、函数等)。

对于结构和数据,这是一个判断。我个人对我的数据库保持一个干净的结构模板,但由于它们的大小,不将它们存储在版本控制中。但是将它存储在版本控制中是非常有益的,即使对于只有历史记录也是如此。

虽然这个问题有很多很好的答案,但大多数答案都不包括市场上的创新变化,特别是商业工具。

下面是一个简短的数据库版本控制工具列表,我列出了每个工具的优缺点(完全披露:我为DBmaestro工作)

红门——已经上市很多年了。它使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。

DBVS——使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。

DBmaestro——在真实的数据库对象上提供版本控制过程(签出/签入)的强制执行。因此,版本控制存储库是否与应用程序使用的数据库同步是没有问题的。

我鼓励您阅读资深数据库专家Ben Taylor在LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro上发布的关于数据库强制变更管理解决方案的全面、公正的评论