重建遗留应用程序:数据模型如何？

Question

我目前正在从头开始重建一个产品目录(为购物网站提供饲料)。现有的遗留系统是异构的，长话短说:一些产品存储在一个FileMaker数据库中(有一个大的意大利面数据模型)，其他产品被编辑成YAML文件.

因此，我的问题是:如果我想逐步迁移到新系统，那么数据建模的策略是什么，也就是说，我是否必须尽快建立一个详尽的数据模型(不同种类的产品，处理分类法，产品变体，库存管理，……)或者，当我添加更多的产品类型时，我可以开始小规模的工作，只对特定类型的产品建模并增长数据模型吗？

“小开始”的优点是，我不需要在一开始就考虑到所有细节(做一些有用的事情--最低限度可行的产品)，但另一方面，这可能意味着早些时候做出的选择从长远来看会使我陷入困境。

什么是最有效的方法？

Answer 1

想得大，开始小。--

我所知道的处理上述情况的最有效方法是以下方法：

• 注意你对整个数据模型的“愿景”，但不要用某些数据库中所有血淋淋的细节来实现它。相反，将模型保持在概念形式中。您可以在白板、一张纸、一些UML绘图工具、一个文字处理程序或任何您喜欢的东西上这样做。它应该是一种形式，您可以轻松和迅速地应用更改在几分钟内，只要有必要。
• 当要实现系统时，以小步骤递增地执行。只详细地充实了模型的各个部分，并且使用模型的这些部分实现了一些业务流程。

概念上的“愿景”将帮助你避免把自己画在角落里，把注意力集中在你的目标上。然而，它不会阻止你提供一个小的，工作的产品很快。这些业务流程的实现将帮助您验证您为数据模型所做的决策是否正确，允许您修复这些决策，以防它们显示缺陷，如果总体概念仍然合理，还会给您一些反馈。

让我补充一下，在过去的几年里，我在一个与您类似的企业项目中工作:用基于Oracle企业数据库的新系统替换旧的遗留系统(大型机)。业务分析人员首先对他们在旧系统中发现的所有属性进行建模，这些属性早在任何真正的业务代码编写之前就已经存在。几年后，整个项目以一场恶搞而告终。造成这种情况的原因有几个，也许数据模型不是主要原因。但超过一半的属性被证明是不合适的，要么是设计不足，要么是设计过度，而周围的整个事物和开发组织都证明了自己在允许拯救项目时过于不灵活。

Answer 2

我处理这个问题的方法是，(在设计和编码方面，我很简单，一步一步地)

1. 如果你有足够的时间，花更多的时间在设计阶段。
2. 研究xml文件和文件制造者数据库的架构。
3. 列出所有单独的属性和面向对象将是最好的坚持在这里。
4. 然后花时间看看它们是否有重叠的属性，一个很好的地方就是检查它们是如何在UI中呈现的。如果它们显示在同一行中--在产品列表中--这可能意味着它们是相似的数据，但可能被不同地调用。例如，xml中的T恤尺寸和数据库中的大小。
5. 构建代码以同化单个条目并将其转换为一个新的混合模型可能是XML的。
6. 构建一个模型测试器，该测试器针对新生成的数据测试xml和db中的数据，以发现缺陷或空白。
7. 您可以在进行更改后经常重新运行此模型测试器，以确保所有数据都已完全转换。

我做了一些类似的工作，把来自不同供应商的代销商提要放在一起。

Answer 3

(考夫，考夫.)有时，我们不得不使用的‘数据模型’只是当时产品de交给我们的那些数据模型。例如，如果“最终可交付的产品”是“一份报告”，那么我们就必须提供它。同样，“您的情况”。

此时:您正在处理“重新实现”。实际上，“你现在所得到的一切”实际上不会“继续下去”。而且，许多数据表示，其中大部分是“技术时代的需要”，也不会继续下去。相反，它们只是“数据来源”。而且，“他们当时所支持的”的技术和技术现在只是建议而已。