【发布时间】：2010-12-13 07:29:55
【问题描述】：
假设我们有一个使用过时技术编写的系统（生产中），难以适应不断变化的业务需求。已决定用更新的技术重写它。我们是否应该从新的数据库模式重新开始，该模式将准确反映新系统的数据模型，但要接受开发数据库转换的风险和成本（由于分阶段的实施计划，必然是双向的）？或者我们应该保持相同的模式，即使它不反映新模型会使开发复杂化，但可以获得消除转换任务的优势？
【问题讨论】：
标签： database-design architecture
【发布时间】：2010-12-13 07:29:55
【问题描述】：
作为开发人员和应用程序维护人员，重新开始使用新架构和应用程序重写是一个经常无法实现的梦想。仅考虑到您问题中的信息，我倾向于选择新架构和转换工作。
但是...
要做出正确的决定，需要大量缺失的信息。比如：该决定将如何影响预算和/或时间表？当前架构有什么问题？等等
所以...
作为项目发起人和业务分析师，我希望通过获得良好的投资回报来证明成本合理。请记住，花在新模式上的任何时间和金钱都是可以用于功能或其他项目的时间和金钱。从这个角度看待它时要问自己的一些问题是：新模式会降低维护成本吗？如果有，多少钱？新模式是否会给我们带来优势，让我们能够更快地添加下一组功能？旧模式是否有一些继承限制使我们无法实现目标？新模式是否会提供性能提升，从而让客户更加满意？等等
恐怕需要全貌，即便如此，一旦你选择了一条道路，你永远不会知道如果你做出不同的选择会变成什么样子。
【讨论】：
-
+1 如果您保留旧模式，您必须根据系统复杂性导致的未来维护成本来评估更改模式的初始额外成本。没有大量分析，没有人能给你答案。也就是说，您还应该谷歌“第二系统综合症”。
我认为您应该重新设计架构。没有理由将旧问题带到新的实施中。 数据转换是一次性任务，需要一些时间，但归根结底 - 从长远来看，您将获得更好的结果。
【讨论】：
-
+1 正好——如果你有机会最终清理一个拙劣的设计——抓住它的角！是的，需要付出努力 - 但通常这远远超过未来的收益（更少的维护噩梦）
-
如果由我决定，每 5 年应该重新编写一个应用程序。对于一个中型应用程序，我发现让人们学习旧技术和维护旧代码的成本，不值得我花费时间和金钱来重新编写应用程序，此外 - 要求非常强大并且易于处理技术升级 - 因此该过程比通常的开发项目要短得多。
如果您有数据库专业人员来帮助您进行设计，我只会考虑重做架构。一般来说，应用程序程序员在设计具有所有检查和平衡业务关键系统需求的高性能数据库方面做得很差。
更改架构并成功移动现有数据比您想象的要困难得多。这将是一项巨大的努力，需要数月的全职工作，而且风险很大。现有数据库越大越复杂，重新设计的难度就越大。
我会考虑的一件事是将旧数据移至数据仓库，然后为未来的数据设计新系统。然后它也会定期将数据发送到数据仓库，以便人们能够查询历史和当前记录。这样，您的新系统可以具有旧数据可能没有的约束，并且您不必尝试找出在所需字段中为没有值的旧数据输入什么值。
如果您正在考虑这一点，您可能还想阅读重构数据库。这是一本关于这个主题的优秀书籍： http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1257433737&sr=8-1
如果没有深入了解您计划用作后端的数据库的性能调整，请不要考虑这样做。如果您不开发性能良好并扩大规模的东西，那么重新设计是没有意义的。忘记那些关于过早优化的垃圾 - 数据库需要从一开始就考虑到性能以及数据完整性和安全性。有许多众所周知的技术可以创造更好的性能，在任何重新设计中都应该考虑这些技术。
【讨论】：
您的数据库应该满足程序的需要，而不是相反。如果您的业务需求发生了变化，毫无疑问数据也发生了变化，如果是我，我会借此机会更新程序，以此来更新数据库以满足您不断变化的需求。您节省不转换数据库的时间，您将浪费在创建 hack 以使其在新程序中工作。
【讨论】：
【讨论】：
您必须权衡开发的额外复杂性所增加的时间与转换数据库所需的时间。
就个人而言，我无法忍受使用与业务需求不完全匹配且无法更改的架构。它总是引入大量的黑客攻击和不良代码气味。
我想开发中的额外复杂性将超过通常简单的 ETL 类型的数据库转换任务。
【讨论】：
我相信你的决定将落入如何，而不是是否或 不要更改架构。在选择解决方案时要自律和彻底。
您应该评估旧系统提供的服务，目的是确认 它满足的所有业务需求也必须由新系统满足。多少钱 新模型不能与旧模型共存（即是否可以解耦部分 复杂的过渡？）您的系统对风险的容忍度如何？
你一次改变的部分越多，你得到你期望的东西的可能性就越小 首先是整个努力。
在您完成迁移的所有机制后，请确保您有办法 验证和量化新系统的特性。你是否还满足所有 业务需求？旧制度的不足真的解决了吗？做 新系统性能更好？它会减少您的维护开销吗？
以此类推。
【讨论】：