【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
我觉得我的商店有一个漏洞，因为我们没有一个可靠的流程来版本化我们的数据库模式更改。 我们做了很多备份，所以我们或多或少都被覆盖了，但以这种方式依赖你的最后一道防线是不好的做法。
令人惊讶的是，这似乎是一个共同点。 我说过的很多商店都忽略了这个问题，因为他们的数据库并没有经常改变，而且他们基本上只是努力做到细致。
但是，我知道这个故事是怎么回事。 事情排列错误只是一个时间问题而且缺少某些东西。
对此有什么最佳做法吗？ 有哪些策略对你有用？
#1楼
我相信每个数据库都应该受源代码控制，开发人员应该有一个简单的方法从头开始创建他们的本地数据库。 受Visual Studio for Database Professionals的启发，我创建了一个脚本MS SQL数据库的开源工具，并提供了将它们部署到本地数据库引擎的简便方法。 试试http://dbsourcetools.codeplex.com/ 。 玩得开心， - 弥敦道。
#2楼
数据库本身？ 没有
创建它们的脚本，包括静态数据插入，存储过程等; 当然。 它们是文本文件，它们包含在项目中，并像其他所有内容一样进行检入和检出。
当然，在理想的世界中，您的数据库管理工具会这样做; 但你必须遵守纪律。
#3楼
我通过保存创建/更新脚本和生成采样数据的脚本来实现。
#4楼
必须阅读在版本控制下获取数据库 。 查看K. Scott Allen的一系列帖子。
在版本控制方面，数据库通常是第二类甚至是三等公民。 从我所看到的情况来看，那些在没有版本控制的情况下永远不会想到编写代码的团队在一百万年之内 - 这是正确的 - 在某种程度上可以完全忘记对应用程序所依赖的关键数据库进行版本控制的需求。 我不知道当你的数据库与其他代码完全没有完全相同的源代码控制级别时，你怎么称自己为软件工程师并保持直面。 不要让这件事发生在你身上。 在版本控制下获取数据库。
#5楼
我非常喜欢Rails ActiveRecord迁移。 它将DML抽象为ruby脚本，然后可以在源存储库中轻松进行版本化。
但是，通过一些工作，你可以做同样的事情。 任何DDL更改（ALTER TABLE等）都可以存储在文本文件中。 保留文件名的编号系统（或日期戳），并按顺序应用它们。
Rails在数据库中还有一个“版本”表，用于跟踪上次应用的迁移。 你可以轻松地做同样的事情。
来源：oschina
链接：https://my.oschina.net/u/3797416/blog/3153187