应对模式演化的策略？

Question

目前，我们在数据访问对象中使用手工编写的SQL以及大量的存储过程和触发器，其代码行数约为20k。我们发现，简单的更改会导致需要几天的工作来修复，这会导致项目进度滑坡。

这些更改包括修改表格以处理额外的数据，根据QA/用户报告重构架构等。这是一个非常活跃的系统，正在建设中以取代旧的、缓慢的系统。

我们考虑查看PHP ORM解决方案以尝试限制这些更改的影响，但它们处理我们的架构时速度太慢了; “简单”sql结果返回所需时间比我们的自定义查询长多个数量级，并导致页面视图从~0.5秒变成超过20秒。

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

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

- Phillip Oldham

---

你能给一个需要很长时间才能实现的变化的例子吗？ - finnw

Answer 1

您可能想要查看这本关于重构数据库：演进式数据库设计的书。

- Jeffrey Fredrick

Answer 2

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

编写存储过程的成本很高，但这将立即识别出错误。
一旦您知道错误出现的位置，就可以修复它。

我很想听听其他人在应用此策略于数据库更改方面的经验。

- AJ

Answer 3

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

- Kieveli

Answer 4

我的建议是摆脱存储过程，改用内联SQL，可以维护在文本/XML文件中。我发现存储过程更加烦人和耗时。一旦查询计划生成（第一次执行查询），您将注意到性能上几乎没有差异。此外，您将能够对整个数据库脚本进行版本控制...

- jacko

---

我点了赞，但XML文件中的SQL？ "<SELECT>SELECT</SELECT><STAR>*</STAR><FROM>FROM</FROM> ... " ? - MusiGenesis

不，更像这样： <Query Name="GetUserDetails">选择用户从用户表中...</Query> - mwjackson

不是主要帖子的一部分；我们的存储过程已经在svn中了 - 我们先在txt文件中编写它们，然后再在数据库中运行。几乎所有我们拥有的东西都在版本控制下。在这种情况下，您将如何处理触发器？ - Phillip B Oldham

Answer 5

以下是我的建议：

1. 尝试摆脱最少使用的功能。质疑不经常使用的功能。应用程序中的每个功能都有几个与之相关的成本层面（维护、支持、回归测试、代码复杂度等）。
2. 除非在代码中没有有效且可扩展的方式，否则请避免使用存储过程。
3. 逐步引入ORM解决方案（使用重构从JDBC到ORM），以减少CRUD操作中的代码量和代码复杂性。
4. 在修复错误时构建功能、集成和单元测试，并将这些测试纳入持续集成系统中。尽可能自动化回归测试，以便在检入时尽早识别问题。
5. 通常情况下，每当您修复错误时，请利用这个机会进行重构，以解耦实现/代码模块。

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

- Shashi Velur