AgileData.org is an excellent resource -- much more than I cram into a single response -- on Agile Database development. In particular, you might be interested in Agile Data Best Practices. If you use SQL Server, you might also be interested in SQL Compare from Red Gate software. Our DBAs have used it to help me migrate changes from QA to Production for existing applications.
enforcing a mechanism whereby the code is locked to the database version, i.e. testing for a value that returns the current version of the DB, if there's a mismatch, the system bails and bleats loudly about the mismatch.
我知道有一些工具可以帮助自动化此过程，例如 Red Gate，但手动创建 SQL 更改文件非常容易。
In our Agile setup, there's a folder for DB changes, done as .SQL files. So far we've had a DB change in every version, and the file is named after the app version. The install script automagically applies all the change files when updating sites.
We also have a full schema dump of a reference DB, that's used for new installs, created by our DB Admin tool.
I know there are tools that help automate this process, such as Red Gate, but manually creating the SQL change file is very easy.
Ideally you make non breaking changes, then when release is done you can fully deprecate old parts of the schema. This is not easy and requires discipline. It is not even always possible.
正如其他人指出的那样，迁移是跟踪架构更改的简单但有效的工具。 这个概念是 CREATE 和 ALTER 语句的脚本，用于从模式的一个修订版升级到下一个修订版，同时伴随着 ALTER 和 DROP 语句的脚本，用于降级相同的更改。 Ruby on Rails 在此之上使用数据库抽象层，以便更轻松地切换数据库品牌，但如果您只需要支持一个品牌，则可以简单地使用 SQL 文件。
The database structure is most likely to be a dependency of many parts of your code, and schema changes will have cascading effects. Kind of like making changes to the interface in a class which many classes extend. So be cautious about schema changes.
Agile methodology is no different than other methodologies in that it's to your benefit to design the database up front as much as possible, and you should seek to change it less frequently than the code. Not to say you can never change it, but it is costly to do so.
Migrations are a simple but effective tool for tracking schema changes, as others have noted. The concept being scripts of CREATE and ALTER statements to upgrade from one revision of the schema to the next, accompanied by scripts of ALTER and DROP statements to downgrade the same changes. Ruby on Rails uses a database abstraction layer on top of this to make it easier to switch brands of database, but if you only need to support one brand you could simply use SQL files.
发布评论
评论（6）
AgileData.org 是关于敏捷数据库开发的优秀资源 - 比我在单个回复中塞进去的内容要多得多。 特别是，您可能对敏捷数据最佳实践感兴趣。 如果您使用 SQL Server，您可能还会对 Red Gate 软件中的 SQL Compare 感兴趣。 我们的 DBA 使用它来帮助我将现有应用程序的更改从 QA 迁移到生产。
AgileData.org is an excellent resource -- much more than I cram into a single response -- on Agile Database development. In particular, you might be interested in Agile Data Best Practices. If you use SQL Server, you might also be interested in SQL Compare from Red Gate software. Our DBAs have used it to help me migrate changes from QA to Production for existing applications.
对于每次更新，我会：
HTH
干杯，
罗布
For each update, I'd be:
HTH
cheers,
Rob
在我们的敏捷设置中，有一个用于数据库更改的文件夹，以 .SQL 文件形式完成。 到目前为止，我们在每个版本中都进行了数据库更改，并且该文件以应用程序版本命名。 更新站点时，安装脚本会自动应用所有更改文件。
我们还有一个参考数据库的完整模式转储，用于新安装，由我们的数据库管理工具创建。
我知道有一些工具可以帮助自动化此过程，例如 Red Gate，但手动创建 SQL 更改文件非常容易。
In our Agile setup, there's a folder for DB changes, done as .SQL files. So far we've had a DB change in every version, and the file is named after the app version. The install script automagically applies all the change files when updating sites.
We also have a full schema dump of a reference DB, that's used for new installs, created by our DB Admin tool.
I know there are tools that help automate this process, such as Red Gate, but manually creating the SQL change file is very easy.
理想情况下，您进行非破坏性更改，然后在发布完成后，您可以完全弃用模式的旧部分。 这并不容易，需要纪律。 这甚至并不总是可能的。
Ideally you make non breaking changes, then when release is done you can fully deprecate old parts of the schema. This is not easy and requires discipline. It is not even always possible.
查看 Ruby on Rails 迁移。 如果您不使用 Rails 也没关系，因为这个想法已经被复制到其他框架了。
Take a look at Ruby on rails migrations. Doesn't matter if you don't use Rails, as the idea has been copied to other framework already.
数据库结构很可能是代码许多部分的依赖项，并且架构更改将产生级联效应。 有点像更改许多类扩展的类中的接口。 因此，要谨慎对待架构更改。
敏捷方法与其他方法没有什么不同，因为尽可能预先设计数据库对您有利，并且您应该寻求比代码更频繁地更改数据库。 并不是说你永远无法改变它，但这样做的成本很高。
正如其他人指出的那样，迁移是跟踪架构更改的简单但有效的工具。 这个概念是 CREATE 和 ALTER 语句的脚本，用于从模式的一个修订版升级到下一个修订版，同时伴随着 ALTER 和 DROP 语句的脚本，用于降级相同的更改。 Ruby on Rails 在此之上使用数据库抽象层，以便更轻松地切换数据库品牌，但如果您只需要支持一个品牌，则可以简单地使用 SQL 文件。
关于这个主题有一本备受推崇的书（尽管我还没有时间购买或阅读它），名为“重构数据库：进化数据库设计”作者：Scott Ambler
The database structure is most likely to be a dependency of many parts of your code, and schema changes will have cascading effects. Kind of like making changes to the interface in a class which many classes extend. So be cautious about schema changes.
Agile methodology is no different than other methodologies in that it's to your benefit to design the database up front as much as possible, and you should seek to change it less frequently than the code. Not to say you can never change it, but it is costly to do so.
Migrations are a simple but effective tool for tracking schema changes, as others have noted. The concept being scripts of CREATE and ALTER statements to upgrade from one revision of the schema to the next, accompanied by scripts of ALTER and DROP statements to downgrade the same changes. Ruby on Rails uses a database abstraction layer on top of this to make it easier to switch brands of database, but if you only need to support one brand you could simply use SQL files.
There's a highly-regarded book on this subject (though I haven't gotten around to buying or reading it yet) called "Refactoring Databases: Evolutionary Database Design" by Scott Ambler