超类型和子类型的含义

Question

对数据库中的整个数据实现超类型和子类型是否不好？在转向这个方向之前，我需要一些建议...

例如，

我将这些表作为对象，并且它们是相关的，

users
pages
images

entities 表作为超类型

entity_id     entity_type
1             page
2             page
3             user
4             user
5             image
6             image

users 表

user_id     entity_id
1           3
2           4

< code>pages 表

page_id     entity_id
1           1
2           2

images 表

image_id     entity_id
1            5
2            6

是用于将 images 表与 entities 表映射的表，因为一些图像属于某个页面（将来可能属于博客文章等），

map_entity_image 表，

entity_id    image_id
1            1
1            2

因此，当我要创建页面、图像、用户等时，我将在 entities 表中插入一行。

最终，该表中的行数将会大量增加。所以我担心它能处理大量的行吗？随着时间的推移，这个数据库会变得越来越慢吗？

毕竟，这些结构是不是很糟糕？

或者也许我错误地执行了超类型/子类型？

编辑：

我认为实体应该只有这些数据，

entity_id     entity_type
1             page
2             page

除非我想将图像附加到用户等，那么它应该是这样的，

entity_id     entity_type
1             page
2             page
3             user
4             user

也许我错了......

编辑：

所以这是我如何找出附加到页面id 1的图像数量的查询，

SELECT E.*, P.*, X.*,C.*
FROM entities E

LEFT JOIN pages P ON (P.entity_id = E.entity_id)

LEFT JOIN map_entities_images X ON (X.entity_id = E.entity_id)

LEFT JOIN images C ON (C.image_id = X.image_id)
WHERE P.page_id = 1

返回2图像。

Answer 1

如果您需要的只是将图像附加到用户和页面，我不确定完整的类别（又名“子类”、“子类型”、“继承”）层次结构是否是最佳选择。

假设页面/用户可以有多个图像，并且任何给定的图像都可以附加到多个页面/用户，并且假设您不想将图像附加到图像，您的模型可能应如下所示：

---

您可以使用类别层次结构来实现类似的结果...

...但是由于子类太少，我建议不要使用它（由于潜在的可维护性和性能问题）。另一方面，如果将来有可能添加新的子类，这实际上可能是正确的解决方案（ENTITY_IMAGE 将自动“覆盖”所有这些新子类，因此您不需要引入新的“链接”每一个表）。

顺便说一句，有3种主要方法来实现类别层次结构，每个类别都有自己的一套权衡。

Answer 2

不完全是您问题的答案，但是，您所描述的并不是大多数建模者所说的“超类型”。

这类似于 OOP 中的超类/子类。超类型是通用实体，子类型是通用实体的更专业的版本

。典型的例子是车辆。 “车辆”具有一组通用属性，例如“所有者”、“价格”、“品牌”、“型号”。无论是汽车、自行车还是船都没关系。然而，汽车有“轮子”、“门”、“发动机尺寸”和“发动机类型”，自行车有“齿轮数”和“地形类型”（BMX、公路等），船有“螺旋桨” 、“帆”和“船舱”。

有两种方法可以实现这一点。

首先有一个“汇总”，您有一个表，其中包含“车辆”的所有公共属性以及每种车辆类型的可选属性。

其次，有一个“rolldown”，您有一个表，其中仅保存每辆车的共同属性。每种车辆类型都有一个表来保存“汽车”、“自行车”和“船”的特定属性。