超类型和子类型的含义

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

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 应该只有这些数据，

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 major ways 来实现类别层次结构，每个都有自己的一组权衡。

Answer 2

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

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

典型的例子是车辆。 “车辆”具有一组共同的属性，例如“所有者”、“价格”、“制造”、“型号”。不管是汽车、自行车还是船。然而，汽车有“轮子”、“门”、“发动机尺寸”和“发动机类型”，自行车有“齿轮数”和“地形类型”（BMX、公路等），船有“螺旋桨” 、“帆”和“船舱”。

有两种实现方式。

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

其次有一个“rolldown”，你有一个表，其中只包含每辆车的共同属性。并且为每种车辆类型提供一个表格，用于保存特定于“汽车”、“自行车”和“船”的属性。