我觉得我的商店有一个漏洞，因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份，所以我们或多或少地得到了保护，但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是，这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题，因为他们的数据库不会经常更改，他们基本上只是尽量做到一丝不苟。
不过，我知道这个故事是怎么发展的。这只是时间问题，迟早会出问题，会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
是的，我们通过保留SQL作为构建的一部分来做到这一点——我们保留DROP。sql,创造。sql,用户。sql,值。SQL和版本控制，所以我们可以恢复到任何带标签的版本。
我们还有ant任务，可以在需要时重新创建db。
此外，SQL还被标记为与之配套的源代码。
其他回答
Sadly, I've seen more than one team developing PL/SQL programs (stored procedures in Oracle) - sometimes ten thousands LOC - just by editing the code in TOAD (a database tool), without even saving the source to files (except for deployment). Even if the database is backuped regulary (wouldn't take that for granted, though), the only way to retrieve an old version of a stored procedure is to restore the whole database, which is many GB large. And of course sometimes concurrent changes in one file lead to loss of work, when more than one developer works on the same project.
我们有一个每周的sql转储到一个颠覆回购。这是完全自动化的，但这是一项非常繁重的任务。
你会想要限制修改的数量，因为它真的会在一段时间后消耗磁盘空间!
是的。代码就是代码。我的经验法则是，我需要能够从头构建和部署应用程序，而不需要查看开发或生产机器。
关于数据库模型本身有很多讨论，但是我们也将所需的数据保存在. sql文件中。
例如，为了让你的应用程序更有用，你可能需要在安装时这样做:
INSERT INTO Currency (CurrencyCode, CurrencyName)
VALUES ('AUD', 'Australian Dollars');
INSERT INTO Currency (CurrencyCode, CurrencyName)
VALUES ('USD', 'US Dollars');
我们会有一个名为currency的文件。subversion下的SQL。作为构建过程中的一个手动步骤，我们将比较以前的货币。SQL到最新版本，并编写升级脚本。
我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本，然后可以在源存储库中轻松地进行版本化。
然而，通过一些工作，您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳)，并按顺序应用它们。
Rails在DB中还有一个'version'表，用于跟踪上一次应用的迁移。你可以很容易地做到这一点。
