将相似实体存储在同一个表中,而不是存储在数据库中的多个表中

2022-03-09 00:00:00 database orm mysql relational-database erd

我们有两个实体要在数据库中表示:
-具有属性(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。如果每个实体没有相关的属性,我看不出它们有多少共同的属性有什么关系。仅仅因为相似的属性而将不相关的数据放在同一个表中,这不是一个好的数据库设计。有关您的架构的更多信息也可能有助于决策。

相关文章