假设我们有一个用过时技术编写的系统（生产中），很难适应不断变化的业务需求。已决定用更新的技术重写它。我们是否应该重新开始使用新的数据库模式来准确反映新系统的数据模型，但接受开发数据库转换的风险和成本（由于分阶段的实施计划，必然是双向的）？或者我们应该保持相同的模式，即使它会使开发变得复杂，因为它不反映新模型，但是获得了消除转换任务的优势？
答案 0 :(得分：9)
作为开发人员和应用程序维护人员，重新开始使用新架构和应用程序重写是一个经常无法实现的梦想。只给出问题中的信息，我倾向于选择新的模式和转换工作。
<强> BUT ...
做出正确决定需要大量缺失的信息。赞：决定将如何影响预算和/或时间表？当前架构有什么问题？等
<强> SO ...
作为项目发起人和业务分析师，我希望通过获得良好的投资回报来证明成本是合理的。请记住，花在新架构上的任何时间和金钱都是可用于功能或其他项目的时间和金钱。从这个角度来看，有些问题要问自己：新模式是否会降低维护成本？如果是这样，多少钱？通过让我们更快地添加下一组功能，新模式是否会给我们带来优势？是否存在一些旧模式的继承限制，使我们无法实现目标？新架构是否会提供性能提升，从而使客户更满意？等
我担心整个画面都是必需的，即使这样，一旦你选择了一条道路，如果你做出了不同的选择，你将永远不会知道它会是什么样的。
答案 1 :(得分：1)
我相信你应该重新设计架构。没有理由把旧问题带到新的实现中。 数据转换是一次性任务，需要一些时间，但最重要的是 - 从长远来看，你会得到更好的结果。
答案 2 :(得分：1)
如果您有一位数据库专家来帮助您完成设计，我只会考虑重做架构。一般而言，应用程序员在设计具有业务关键系统所需的所有检查和平衡的性能数据库方面做得很差。
更改架构并成功移动现有数据比您想象的要困难得多。这需要数月的全职工作才能付出巨大的努力，而且风险很大。现有数据库越大越复杂，重新设计就越困难。
我要考虑的一件事是将旧数据移动到数据仓库，然后为未来的数据设计新系统。然后它会定期向数据仓库发送数据，以便人们能够查询历史记录和当前记录。这样，您的新系统可能具有旧数据可能没有的约束，您将不必尝试找出在没有值的旧数据的必填字段中放入的值。
如果您正在考虑这个问题，您可能还想阅读重构数据库。这是一本关于这个主题的优秀书籍： http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1257433737&sr=8-1
另外，如果没有深入了解有关调整计划用作后端的数据库的性能，请不要考虑这样做。如果你不开发能够表现良好并且能够扩展的东西，那么重新设计就没有意义了。忘记关于过早优化的垃圾 - 数据库需要从一开始就设计性能以及数据完整性和安全性。有许多众所周知的技术可以创建更好的性能，在任何重新设计中都应该考虑这些技术。
答案 3 :(得分：0)
您的数据库应该满足程序的需要，而不是相反。如果您的业务需求发生了变化，毫无疑问数据也会发生变化，如果是我，我会利用这个机会更新程序，以此作为更新数据库的机会，以满足您不断变化的需求。保存不转换数据库的时间，您将浪费创建黑客以使其在新程序中工作。
答案 4 :(得分：0)
答案 5 :(得分：0)
您必须权衡开发的其他复杂性所带来的时间与转换数据库所需的时间。
就个人而言，我无法忍受使用不能准确匹配业务要求且无法更改的架构。它总是会引入很多黑客和糟糕的代码气味。
我认为开发中的其他复杂性将超过通常直接的ETL类型的数据库转换任务。
答案 6 :(得分：0)
我相信你决定的内容将属于如何，而不是是否 不要改变架构。在选择解决方案时要严格遵守纪律。
您应该评估旧系统提供的服务，目的是确认 它满足的所有业务要求也必须由新系统满足。多少 新模型不能与旧模型共存（即可以将各部分分离 一个复杂的过渡？）你的系统有多大的风险？
您一次更换的碎片越多，获得预期的可能性就越小 从一开始的整个努力。
在完成迁移的所有机制之后，请确保您有方法 验证和量化新系统的特征。你还满足所有人吗？ 业务要求？旧系统的不足之处是否真正得到了解决？是否 新系统表现更好？它是否会降低您的维护费用？
等等。