问为什么人们将运输和处理存储在订单标头而不是行项中？

EN

我问你这个问题。如果我订购了100件商品，然后改变主意，要求只有50件才能发货，那么船运会下降吗？换句话说，无论订购的是什么，还是根据订单中的各个项目计算的，每个订单的运费都不会改变。如果你运输重物，它很可能是基于订购的物品，因此储存在那里。如果您运送的东西较轻，很可能每个订单的费用都是标准的，应该存储在父表中。

我认为将运输、处理、税收等作为计算字段放在报头上的理由是双重的。

1. 开发人员可能更喜欢这种风格，因为在遗留应用程序中工作过，我注意到许多来自90年代中期的开发人员倾向于使用带有计算字段的平面表设计。
2. 软件的设计者可能不知道在这个领域使用一种更加规范化的软件设计方法。如果我正在介绍运行的UI航运，Hanlding，Tax，通常是作为订单总括过程的一部分显示的值的总和。

显然，代码的作者没有区分域模型和视图模型或域模型的视图方面。假设两者紧密结合，这是可以理解的。

如果我要给出我的意见，哪条路线是最好的，我会采用规范化的方法，提供航运，处理，税收和其他费用作为行项目，以减少任何计算字段的订单报头。然后，如果有必要，我会将它们作为ViewModel中的求和值提供，但只作为UI显示的产品，而不是作为数据存储的方法。

把它想成这样:一个单独的发货订单将多个项目发送到一个地址。从这个简单的短语中，您可以推断出不同数据位之间的实体关系。一个运输订单与项目有一对多的关系，因此主细节形式。另一方面，送货订单与传送地址有一对一的关系，因此它们是同一表单的一部分，而在规范化DB中，它们将是同一个表的一部分。