0

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

例如，

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

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

这是将表格与表格进行映射 的表格，因为某些图像属于某个页面（可能是将来的博客文章等），imagesentities

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张图像。

4

2 回答 2

1

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

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

在此处输入图像描述

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

在此处输入图像描述

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

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

于 2012-02-24T04:32:10.937 回答
0

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

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

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

有两种实现方式。

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

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

于 2012-02-24T02:34:38.193 回答