Joe*_*Fan 4 architecture database-design
假设我们有一个用过时技术编写的系统(生产中),很难适应不断变化的业务需求.已决定用更新的技术重写它.我们是否应该重新开始使用新的数据库模式来准确反映新系统的数据模型,但是接受开发数据库转换的风险和成本(由于分阶段的实施计划,必须是双向的)？或者我们应该保持相同的模式,即使它会使开发复杂化,因为它不反映新模型,但是获得了消除转换任务的优势？
作为开发人员和应用程序维护人员,重新开始使用新架构和重写应用程序是一个经常无法实现的梦想.只给出问题中的信息,我倾向于选择新的模式和转换工作.
但...
做出正确决定需要大量缺失的信息.赞:决定将如何影响预算和/或时间表？当前架构有什么问题？等等
所以...
作为项目发起人和业务分析师,我希望通过获得良好的投资回报来证明成本是合理的.请记住,花在新架构上的任何时间和金钱都是可用于功能或其他项目的时间和金钱.从这个角度来看,有些问题要问自己:新模式是否会降低维护成本？如果是这样,多少钱？通过让我们更快地添加下一组功能,新模式是否会给我们带来优势？是否存在一些旧模式的继承限制,使我们无法实现目标？新架构是否会提供性能提升,从而使客户更满意？等等
我担心整个画面是必要的,即使这样,一旦你选择了一条道路,如果你做出了不同的选择,你将永远不会知道它会如何发展.