应对模式演变的策略? [英] Stategies for coping with schema evolution?

问题描述

目前，我们在数据访问对象和大量存储过程和触发器中使用手动 SQL，总计约 20k 行代码.我们发现，简单的更改会导致需要几天的工作才能修复，并且会导致截止日期推迟.

Currently we're using hand-rolled SQL in Data-Access objects and a lot of stored-procedures and triggers which amount to around 20k lines of code. We're finding that simple changes are causing a couple of days' work to fix, and its causing deadlines to slip.

更改包括修改表以处理额外数据、基于 QA/用户报告对架构进行一般重构等.它是一个非常活跃的系统，旨在取代旧的和缓慢的东西.

Changes include modifications to tables to cope with additional data, general refactoring of the schema based on QA/user reports, etc. Its a very active system that's being built to replace something old and slow.

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

We looked at the PHP ORM solutions available to try and limit the effects of these changes, but they were just too slow to cope with our schema; "simple" sql results were taking orders of magnitude longer to return than our custom queries and caused page views of ~.5s to take over 20s.

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

What best-practices/strategies could I look into to cope with schema evolution with relational databases, in a general context?

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

forgot to mention about the triggers; we have a lot of data which relies on cascading changes, eg. a price change here for this user updates a price there for that user, etc.

推荐答案

您可能想在 重构数据库:进化数据库设计.

这篇关于应对模式演变的策略?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！