database - 处理模式演变的策略?




continuous-integration agile (4)

我建议使用连续(或至少每晚)构建策略。
在每次签到时重建数据库,或至少每天一次。
也是每天一次,运行单元测试来锻炼每一位代码,无论是在存储程序,触发器还是数据访问层。

编写存储过程需要花费很大的代价,但这会立即识别出中断。
一旦你知道中断的地方,你可以修复它。

我有兴趣听听其他人对这个策略的经验应用于数据库的变化。

目前,我们在Data-Access对象中使用手动滚动的SQL,并使用了大量的存储过程和触发器,这些存储过程和触发器的数量约为20k行代码。 我们发现简单的变化导致了几天的工作要解决,并导致最后期限的滑落。

变化包括对表格的修改以处理额外的数据,基于QA /用户报告的模式的一般重构等等。它是一个非常活跃的系统,用来替代旧的和慢的东西。

我们研究了可用的PHP ORM解决方案,试图限制这些变化的影响,但是它们太慢了,无法应付我们的模式; “简单”的sql结果比我们的自定义查询返回的时间要长得多,并导致〜.5s的页面访问超过20秒。

在一般情况下,我可以研究哪些最佳实践/策略来处理与关系数据库的模式演进?

编辑:忘了提及触发器; 我们有很多依赖级联变化的数据,例如。 此用户的价格变化在此为该用户更新价格等。


我的建议是摆脱存储过程,而是使用内联SQL,也许保留在文本/ XML文件。 我发现SProcs更烦人,更费时间维护。 一旦生成查询计划(第一次执行查询),您将注意到性能上的差异可以忽略不计。 另外,你将能够版本控制你的整个数据库脚本...


我们使用Enterprise Architect来进行数据库定义。 我们包含存储过程,触发器和UML中定义的所有表定义。 该计划的三大亮点是:

  1. 从ODBC连接导入UML图。
  2. 一次为整个数据库生成SQL脚本(DDL)
  3. 生成您的数据库的自定义模板化文档。

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

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


这是我的建议:

  1. 尽量摆脱最少使用的功能。 质疑未被使用的功能。 应用程序中的每个功能都与其相关的几个成本级别(维护,支持,回归测试,代码复杂性等)。
  2. 远离存储过程,除非绝对没有办法在代码中有效地进行扩展。
  3. 逐渐引入一个ORM解决方案(使用重构从JDBC到ORM),以减少CRUD操作中的代码量和代码复杂度
  4. 当您修复一个错误并将这些测试合并到持续集成系统时,构建功能性,集成和单元测试。 尽可能多地自动化回归测试,以便在检入时尽快发现问题。
  5. 一般来说,每当修复一个bug时,就利用这个机会来重构解耦实现/代码模块。

如果您有关于数据库迁移问题的疑问,可以参考这个问题: http : //shashivelur.com/blog/2008/07/hibernate-db-migration/





agile