我觉得我的商店有一个漏洞，因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份，所以我们或多或少地得到了保护，但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是，这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题，因为他们的数据库不会经常更改，他们基本上只是尽量做到一丝不苟。
不过，我知道这个故事是怎么发展的。这只是时间问题，迟早会出问题，会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
关于数据库模型本身有很多讨论，但是我们也将所需的数据保存在. sql文件中。
例如，为了让你的应用程序更有用，你可能需要在安装时这样做:
INSERT INTO Currency (CurrencyCode, CurrencyName)
VALUES ('AUD', 'Australian Dollars');
INSERT INTO Currency (CurrencyCode, CurrencyName)
VALUES ('USD', 'US Dollars');
我们会有一个名为currency的文件。subversion下的SQL。作为构建过程中的一个手动步骤，我们将比较以前的货币。SQL到最新版本，并编写升级脚本。
其他回答
这对我来说也一直是一个很大的烦恼——似乎对开发数据库进行快速更改，保存它(忘记保存更改脚本)太容易了，然后你就卡在那里了。您可以撤消刚才所做的并重新做它以创建更改脚本，当然，如果您愿意的话，也可以从头开始编写它，尽管这将花费大量的时间来编写脚本。
A tool that I have used in the past that has helped with this some is SQL Delta. It will show you the differences between two databases (SQL server/Oracle I believe) and generate all the change scripts necessary to migrate A->B. Another nice thing it does is show all the differences between database content between the production (or test) DB and your development DB. Since more and more apps store configuration and state that is crucial to their execution in database tables, it can be a real pain to have change scripts that remove, add, and alter the proper rows. SQL Delta shows the rows in the database just like they would look in a Diff tool - changed, added, deleted.
一个很好的工具。以下是链接: http://www.sqldelta.com/
我们使用复制和集群来管理数据库以及备份。我们使用Serena来管理SQL脚本和配置实现。在进行配置更改之前，我们将执行备份，作为更改管理流程的一部分。此备份满足我们的回滚需求。
我认为这完全取决于规模。您是在谈论需要离线备份和灾难恢复的企业应用程序吗?一个运行会计应用程序的小工作组?还是两者之间的任何地方?
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不是必需的。此外，如果您的部署过程是无懈可击的，那么您很可能永远不需要“回滚”您的生产环境。
我已经使用RedGate SQL Compare Pro与脚本文件夹进行模式同步，然后我将所有更新提交给版本控制。效果很好。
虽然这个问题有很多很好的答案，但大多数答案都不包括市场上的创新变化，特别是商业工具。
下面是一个简短的数据库版本控制工具列表，我列出了每个工具的优缺点(完全披露:我为DBmaestro工作)
红门——已经上市很多年了。它使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。
DBVS——使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。
DBmaestro——在真实的数据库对象上提供版本控制过程(签出/签入)的强制执行。因此，版本控制存储库是否与应用程序使用的数据库同步是没有问题的。
我鼓励您阅读资深数据库专家Ben Taylor在LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro上发布的关于数据库强制变更管理解决方案的全面、公正的评论
