应对模式演变的策略？

Question

目前，我们在数据访问对象和大量存储过程和触发器中使用手动SQL，这些过程和触发器大约有20k行代码。我们发现这些简单的更改导致了几天的修复工作，导致最后期限失效。

更改包括对表格的修改以应对其他数据，基于QA /用户报告的模式的一般重构等。它是一个非常活跃的系统，用于替换旧的和缓慢的东西。

我们查看了可用于尝试限制这些更改效果的PHP ORM解决方案，但它们太慢而无法应对我们的架构; “简单”的sql结果比我们的自定义查询花费的数量级更长，导致〜.5s的页面浏览量超过20秒。

在一般情况下，我可以研究哪些最佳实践/策略来应对关系数据库的模式演变？

编辑：忘记提及触发器;我们有很多依赖于级联变化的数据，例如。此处用户的价格更改会为 用户等更新那里的价格

Answer 1

您可能希望在Refactoring Databases: Evolutionary Database Design上查看此书。

Answer 2

我建议使用连续（或至少每晚）构建策略 每次登记时重建数据库，或者每天至少重建一次 每天一次，运行单元测试来运行每一段代码，无论是在存储过程，触发器还是数据访问层。

编写存储过程有很大的成本，但这会立即识别中断 一旦你知道休息的位置，就可以修复它。

我有兴趣听听其他人使用此策略的经验应用于数据库更改。

Answer 3

我们使用Enterprise Architect作为数据库定义。我们包括存储过程，触发器和UML中定义的所有表定义。该计划的三大亮点是：

1. 从ODBC连接导入UML图。
2. 立即为整个数据库生成SQL脚本（DDL）
3. 生成数据库的自定义模板文档。

作为开发人员，我在10多年的时间里从未对任何其他工具印象深刻。 EA一举支持Oracle，MySQL，SQL Server（多个版本），PostGreSQL，Interbase，DB2和Access。任何时候我遇到问题，他们的论坛都会及时回答我的问题。强烈推荐!!

当DB更改进来时，我们在EA中创建，生成SQL，并将其检入我们的版本控制（svn）。我们使用Hudson进行构建，当它看到您修改了签入的sql时，它会自动从脚本构建数据库。

Answer 4

我的建议是删除存储过程，而是使用内联SQL，可能在text / xml文件中维护。我发现SProcs更难以维护并且耗费时间。生成查询计划后（第一次执行查询），您会发现性能差异可以忽略不计。另外，您还可以控制整个数据库脚本...

Answer 5

以下是我的建议：

1. 尝试摆脱使用最少的功能。质疑一直没有使用的功能。应用程序中的每个功能都有几个与之相关的成本（维护，支持，回归测试，代码复杂性等）。
2. 远离存储过程，除非绝对没有办法在代码中以可扩展的方式有效地执行此操作。
3. 逐步引入ORM解决方案（使用重构从JDBC迁移到ORM）以减少CRUD操作中的代码量和代码复杂性
4. 在修复错误并将这些测试合并到Continuous集成系统时构建功能，集成和单元测试。尽可能自动化您的回归测试，以便在办理登机手续时立即发现问题。
5. 一般情况下，每当修复错误时，请利用该机会重构以解耦实现/代码模块。

如果您对数据库迁移问题有疑问，可能会有所帮助：http://shashivelur.com/blog/2008/07/hibernate-db-migration/