相关疑难解决方法(0)

我想让我的数据库受版本控制.有没有人有任何建议或推荐的文章让我开始？

我总是希望在那里至少有一些数据(如alumb提到的:用户类型和管理员).我还经常需要大量生成的测试数据来进行性能测量.

跟踪和/或自动化数据库架构更改的最佳方法是什么？我们的团队使用Subversion进行版本控制,我们已经能够以这种方式自动完成一些任务(将构建推送到临时服务器,将经过测试的代码部署到生产服务器),但我们仍在手动执行数据库更新.我想找到或创建一个解决方案,使我们能够跨不同环境的服务器高效工作,同时继续使用Subversion作为后端,通过该后端将代码和数据库更新推送到各种服务器.

许多流行的软件包都包含自动更新脚本,可以检测数据库版本并应用必要的更改.这是否是即使在更大规模(跨多个项目,有时还有多种环境和语言)中实现这一目标的最佳方式？如果是这样,是否有任何现有的代码可以简化流程,或者最好只是推出我们自己的解决方案？有没有人之前实现过类似的东西并将它集成到Subversion post-commit钩子中,或者这是一个坏主意？

虽然支持多个平台的解决方案更可取,但我们肯定需要支持Linux/Apache/MySQL/PHP堆栈,因为我们的大多数工作都在该平台上.

你如何准备你的SQL增量？您是否手动将每个架构更改SQL保存到增量文件夹,或者您是否有某种自动化的差异化过程？

我对版本化数据库模式以及源代码的约定感兴趣.也许是一个预先提交的钩子来区分架构？

此外,除了DbDeploy之外还存在哪些差异增长的选项？

编辑:看到答案我想澄清一点,我熟悉使用增量运行数据库迁移的标准方案.我的问题是关于自己创建增量,最好是自动创建增量.

此外,版本控制适用于PHP和MySQL,如果它有所作为.(请不要使用Ruby解决方案).

如果在部署应用程序后数据发生更改,您如何使数据库保持最新？

我的意思是,你可以添加或删除表,这是一个简单的任务.改变现有的表也很简单.但是如果你经常改变结构,你如何控制它呢？

我曾经在数据库中保留一个包含当前数据库版本的表.然后每次升级都是一个完成其工作的SQL文件 - 创建新表,添加列或移动数据.文件是以这些版本命名的 - 所以如果我的升级脚本获得了数据库版本10,它只是将11.sql中的所有文件都带到N.sql并同时应用它们中的每一个递增数据库版本号.

这似乎工作正常,但我想知道 - 你的策略是什么？
如果我在一个"补丁"中对一个表进行规范化,那么这个系统似乎并不完美,之后我再次将其归一化为无论什么原因.然后它完成了两次.

但是,每次我改变一些东西时写一个完整的升级脚本似乎很痛苦,容易出错.至少更多这样的原子变化.

此外,我可以预期不同的客户可以随时运行不同的数据库版本,所以我真的应该有办法从任何一点上升.