超类型和子类型的含义

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中的超级/子类。超类型是genric实体，子类型是通用实体的更专业版本

经典的例子是车辆。 “车辆”具有一组共同的属性，如“所有者”，“价格”，“制造”，“模型”。无论是汽车，自行车还是船只都无所谓。然而，汽车有“轮子”，“门”，“发动机大小”和“发动机型”，自行车有“齿轮数”和“地形”（BMX，道路等），船有“螺旋桨” ，“帆”和“小屋”。

有两种实现方法。

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

其次是“rolldown”，你有一个表只保存每辆车的公共属性。并且每种车型都有一个表格，用于保存“汽车”，“自行车”和“船只”的特征。