6

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

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

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

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

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

4

5 回答 5

3

您可能想查看这本关于重构数据库:进化数据库设计的书。

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

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

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

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

于 2008-11-20T16:39:42.267 回答
2

我们使用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 时,它会从脚本中自动构建数据库。

于 2008-11-21T14:17:17.437 回答
1

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

于 2008-11-20T10:09:10.310 回答
0

以下是我的建议:

  1. 尝试摆脱最少使用的功能。质疑一直不使用的功能。应用程序中的每个功能都有与其相关的多个级别的成本(维护、支持、回归测试、代码复杂性等)。
  2. 远离存储过程,除非绝对没有办法在代码中以可扩展的方式高效地完成它。
  3. 逐步引入 ORM 解决方案(使用重构从 JDBC 迁移到 ORM)以减少 CRUD 操作中的代码量和代码复杂度
  4. 当您修复错误并将这些测试合并到持续集成系统中时,构建功能、集成和单元测试。尽可能自动化您的回归测试,以便在签入时立即识别问题。
  5. 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/

于 2008-12-08T04:45:05.463 回答