将相似实体存储在同一个表中，而不是存储在数据库中的多个表中 [英] Storing similar entities in the same table vs in multiple tables in the database

问题描述

我们有两个实体要在数据库中表示：
-具有属性(x，y，z，r)的实体A。
-具有属性(x，y，z，s)的实体B。

这两个实体有3个相同的属性，而只有1个不同的属性。尽管它们非常相似，但它们并不相关，也不打算在业务逻辑中一起使用。

有两种(可能更多)方法来表示这些：

1. 创建两个单独的表，每个实体一个。
   这就是直截了当的方法。它产生了两个相对较小的表，以及更清晰的查询和业务逻辑。但是这些表几乎完全相同，因此在某种程度上显然是冗余的(假设完全相同的属性远远不止3个)。
2. 创建一个具有5个属性(x，y，z，r，s，type)的共享表。
   (Type)指示此行中表示的实体的类型(A或B)。这假设属性(R)和(S)不是必需的，因此我们不能依赖它们来确定实体的类型。
   例如，这是Wordpress用来表示帖子和页面(以及其他一些实体)的方法。它导致一个相对较大的表，其中包含许多null字段，以及相对杂乱的查询和业务逻辑，以过滤各行并在逻辑上分隔实体。但是我们最终只有一个唯一的表，而不是两个冗余的表。

我的问题是：

1-每种方法的其他优点和缺点是什么？

2-这两种方法的用例是什么？

3-如果实体数量增加，或者它们的关系复杂性增加，其中一种方法会明显优于另一种方法吗？例如，如果不是2个实体，而是20个实体。或者这些实体与数据库中的其他实体具有多对多关系。

谢谢！

推荐答案

这两个实体有3个相同的属性，而只有1个不同的属性。虽然它们非常相似，但不相关，不打算在业务逻辑中一起使用。

如果对您的模式/模型没有更多的了解，我会说如果这两个实体具有相似的属性，但在业务逻辑中"不相关"，我强烈建议采用方法1。如果每个实体没有相关的属性，我看不出它们有多少共同的属性有什么关系。仅仅因为相似的属性而将不相关的数据放在同一个表中，这不是一个好的数据库设计。有关您的架构的更多信息也可能有助于决策。

这篇关于将相似实体存储在同一个表中，而不是存储在数据库中的多个表中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！