在数据库数据模型中，更平坦的模型会更高效，还是风险更大？

Question

假设我正在为在线卖家创建数据模型。该公司将在全国范围内拥有许多仓库，就像亚马逊一样。

（挑选者是在仓库工作的人，他从货架上挑选商品，然后打包装箱。）

这是我到目前为止创建的数据模型：

我想到了另一种可以做到的方式，一种更平坦的设计:(区别在于红色。）

缺点 - 应用程序可能会将错误数据放入数据库。但也许我可以相信高级别的开发人员不这样做。

优点 - 用于报告的SQL查询现在更简单。如果我想查询我们从特定供应商那里获得多少总销售额，那么现在可以少一个表来加入。我不再需要加入Product表了。这使查询更简单。

模型＃2是个好主意，还是风险不值得呢？

Answer 1

展平层次结构是报告系统的一个好主意，但通常不适用于OLTP。该概念共享OLAP和数据仓库应用程序的架构设计技术的一些属性，通常称为星型架构。层次结构越平坦，编写和构建查询就越容易。此外，查询可以更快地运行。

此类设计存在的问题是，无法直接从架构在数据库级别检测到某些业务规则。例如，在第二个设计的情况下，Order行可以包含VendorID和ProductID的任意组合，而在第一个设计中，这不可能发生。

如果您的数据库仅由您的应用程序（不是企业应用程序）共享，并且您控制执行更新的代码并且您愿意涵盖此类缺失的业务规则，并且您拥有大量数据，则第二个设计可能是在你的情况下有效。

您需要注意的一点是，您可以反过来绘制代表大多数关系的线条。也就是说，当你拥有一对多的FK时，带有爬行脚的线就会落在很多方面。

Answer 2

当处理缺乏更好类别的数据时，企业家......从不试图压扁数据库。

数据库展平仅用于数据不是100％积分的实际大型应用程序。无法保证原子力的地方，也不需要。

我说，坚持你原来的设计。稍后当你必须在各种表格中对设计和代码（可能为不同的标志添加几个额外的列）实施许多小的更改时，你会感恩的...

同样最重要的一点就是让一切都相关而不是平坦的是你在一个地方做出改变，一切都向下/向上/向侧面移动（取决于你如何设置数据库约束）。

但是，采用平坦的方法，您必须始终记住您所有的表格都已进行更改，否则您的数据会中断或未来的“报告”将无法获得准确的信息。

此外，您始终可以使用各种ORM工具来简化报告。你永远不必担心加入表...只需使用工具..然后它就像

一样简单

table1-＆gt; relation-＆gt;相关的列 - ＆gt;更多关系 - >第三级关系中的列，用于寻址任何列..

有许多针对各种语言的独立ORM工具。