mysql - 父类(super class)型和子类型的含义

Question

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

例如，

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

users
pages
images

entities 表作为父类(super class)型

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

用户表

user_id     entity_id
1           3
2           4

页面表格

page_id     entity_id
1           1
2           2

图像表

image_id     entity_id
1            5
2            6

这是将images表与entities表映射的表，因为某些图像属于特定页面(可能是博客文章等) future )，

map_entity_image 表

entity_id    image_id
1            1
1            2

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

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

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

或者也许我错误地执行了父类(super class)型/子类型？

编辑:

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

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