我已经意识到我必须开始对数据库模式和更改进行版本控制。因此，我阅读了有关该主题的现有帖子，但我不确定如何继续。
我基本上是一家单人公司，不久前我什至没有对我的代码使用版本控制。我在 Windows 环境中，使用 Aptana (IDE) 和 SVN（带有 Tortoise）。我从事 PHP/mysql 项目。
什么是有效且足够（不过分）的方式来版本化我的数据库模式？
我在某些项目中确实有一两个自由职业者，但我预计不会发生大量分支和合并。所以基本上我想跟踪我的代码修订的并发模式。
[edit] 瞬间解决：目前，我决定每当我要提交标签（稳定版本）时，我都会制作一个模式转储加上一个包含必要的初始数据的模式转储。在现阶段这对我来说似乎已经足够了。[/编辑]
[edit2]加上我现在还使用第三个名为increments.sql的文件，其中我将所有更改与日期等放在一起，以便轻松跟踪一个文件中的更改历史记录。有时我会将更改集成到其他两个文件中并清空increments.sql[/edit]
对于小公司来说，简单的方法是：将数据库转储到 SQL 并将其添加到存储库中。然后，每次更改某些内容时，都将更改添加到转储文件中。
然后，您可以使用 diff 来查看版本之间的更改，更不用说使用注释来解释您的更改了。这也将使您几乎不受 MySQL 升级的影响。
我看到的一个缺点是您必须记住手动将 SQL 添加到转储文件中。你可以训练自己永远记住，但如果你和别人一起工作的话要小心。错过更新可能会在以后带来痛苦。
这可以通过在提交到 subversion 时创建一些复杂的脚本来为您完成此操作来缓解，但这对于一个人来说有点太多了。
Edit:在回答这个问题之后的一年里，我不得不为一个小团队实施 MySQL 版本控制方案。手动添加每个更改被认为是一个麻烦的解决方案，就像评论中提到的那样，因此我们转储数据库并将该文件添加到版本控制中。
我们发现测试数据最终被转储，并且很难找出发生了什么变化。这可以通过仅转储模式来解决，但这对于我们的项目来说是不可能的，因为我们的应用程序依赖于数据库中的某些数据来运行。最终我们返回到手动添加对数据库转储的更改。
这不仅是最简单的解决方案，而且还解决了某些版本的 MySQL 在导出/导入方面存在的某些问题。通常我们必须转储开发数据库，删除任何测试数据、日志条目等，删除/更改某些适用的名称，然后才能创建生产数据库。通过手动添加更改，我们可以准确地控制生产中最终会发生什么，每次一点点，以便最终一切准备就绪，并尽可能轻松地迁移到生产环境。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
