database - 应对模式演变的策略？

Question

目前，我们在数据访问对象和大量存储过程和触发器中使用手动 SQL，总计大约 20k 行代码。我们发现，简单的更改会导致几天的工作得以修复，并导致最后期限的推迟。

更改包括修改表以处理额外的数据、基于 QA/用户报告的架构的一般重构等。它是一个非常活跃的系统，正在构建以替换旧的和缓慢的东西。

我们查看了可用的 PHP ORM 解决方案来尝试限制这些更改的影响，但是它们太慢了，无法应对我们的模式；“简单” sql 结果的返回时间比我们的自定义查询要长几个数量级，并导致约 0.5 秒的页面浏览量超过 20 秒。

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

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

score 3 · Accepted Answer

3

于 2008-11-21T16:38:31.943 回答

score 2 · Accepted Answer

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

编写存储过程的成本很高，但这将立即识别中断。
一旦你知道中断在哪里，你就可以修复它。

我很想听听其他人将这种策略应用于数据库更改的经验。

score 2 · Accepted Answer

我们使用Enterprise Architect进行数据库定义。我们包括在 UML 中定义的存储过程、触发器和所有表定义。该程序的三个出色功能是：

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

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

score 1 · Accepted Answer

我的建议是摆脱存储过程，而是使用内联 SQL，可能在 text/xml 文件中维护。我发现 SProcs 更烦人且维护起来更耗时。一旦生成查询计划（第一次执行查询），您会注意到性能差异可以忽略不计。另外，您将能够对整个数据库脚本进行版本控制...

score 0 · Accepted Answer

以下是我的建议：

尝试摆脱最少使用的功能。质疑一直不使用的功能。应用程序中的每个功能都有与其相关的多个级别的成本（维护、支持、回归测试、代码复杂性等）。
远离存储过程，除非绝对没有办法在代码中以可扩展的方式高效地完成它。
逐步引入 ORM 解决方案（使用重构从 JDBC 迁移到 ORM）以减少 CRUD 操作中的代码量和代码复杂度
当您修复错误并将这些测试合并到持续集成系统中时，构建功能、集成和单元测试。尽可能自动化您的回归测试，以便在签入时立即识别问题。
In general, whenever you fix a bug, use that opportunity to refactor to decouple the implementations/code modules.

If you have have questions about Database migration problems, this might help: http://shashivelur.com/blog/2008/07/hibernate-db-migration/

5 回答 5