1

如果我有类似这样的架构： 

TABLE 1  
id  
column  
other_column  
etc

TABLE 2  
id  
table1_id  
some_other_table_id

像这样添加第三个表是个好主意： 

TABLE 3  
id  
table2_id  
row_from_another_table_id

编辑：
为了让事情更清楚，考虑这样的模式：

EVENTS  
id  
name  
other_stuff 

RANGES  
id  
time_from  
time_to  
max_people  
etc

EVENTS_PLACES  
id  
event_id  
place_id

我想做的是为事件定义一个时间范围。但是特定地点的特定事件（EVENTS_PLACES）可以“覆盖”这个范围。一个事件也可以有多个范围。

我希望这让这个问题现在更清楚一点。

4

3 回答 3

2

我一直认为多对多关系违反了Boyce-Codd 范式，因此违反了良好的关系数据库模式。

因此，事实上，将数据与链接表相关联是实现 BCNF 所必需的，因此是好的。如果避免数据更新异常是好的。

转到您提供的特定模式示例。我认为您想要这些逻辑表（或实体），

-----------------------
EventClass
-----------------------
Id
Name
... Other attributes common to every instance
-
-----------------------
TimeSlot
-----------------------
Id
Start
End
-
-----------------------
Place
-----------------------
Id
Name
Address
MaxAttendance
... etc
-
----------------------
EventInstance
-----------------------
Id
EventClassId
TimeSlotId
PlaceId
PresenterName
...Other attributes specific to the instance

EventInstance是 和 之间的关系，EventClass任何特定于 的属性都应该存储在该实体上。相关事件组共有的任何属性都应存储在该属性上。TimeSlotPlaceEventInstanceEventClass

这都是数据库规范化的问题，一般来说，数据越规范化越好。然而，当性能受到关注时，存在妥协的情况，如果所需的数据以输出格式存储，它确实使选择查询更简单、更快，尽管更新可能是地狱。

我会建议通过正确的 Indecies、Materialized Views和 Indecies on Materialized Views来抵消妥协的情况，您可以获得两全其美的效果。完全规范化数据的可维护性与性能速度。虽然，它确实需要一些技巧和考虑才能使架构正确。

于 2012-11-23T10:15:02.567 回答
1

因此，您在两个具有属性的表之间有一个关系，并且您有一个具有更多属性的该关系的子类。这很少见，但可能。

假设在您的一夫多妻异性交友网站中，一个或多个女人实体与一个或多个男人有关系。这两个表可以与联结表Relationship 耦合。现在他们中的一些人结婚了，你认为这是一种特殊的关系。所以Marriage是Relationship的子类，Marriage表有Relationship表中id的引用。

当然，用另一种方式解决这种情况可能更简单，例如在男人和女人之间简单地有两个连接表。但是在某些情况下，您肯定希望扩展联结表中的关系。

于 2012-11-14T10:45:06.427 回答
0

另一种选择是在 TABLE2 中添加一列，描述“事物”之间连接的性质。例如，一个 PERSON 表和一个 RELATIONSHIPS 表，您在第一个表中建模您的“对象”，然后在几秒钟内建模“链接”，例如

+---------+---------+-------+--------+
| link_id | from_id | to_id |  type  |
+---------+---------+-------+--------+
|       1 |       2 |     3 | Mother |
|       2 |       8 |     3 | Sister |
+---------+---------+-------+--------+

使用适当的索引，这意味着您可以执行诸如查找给定人的所有关系或查找所有有姐妹的人等操作。这是一个简单的示例，但是当 from_id 和 to_id 可以是不同的类型时，它开始变得有趣对象即不仅仅是人。

过去，我在使用非常通用的模式时使用过这种方法，该模式聚合来自各种其他来源的数据并且必须灵活。显然，在灵活性和速度、查询复杂性之间需要权衡取舍。您必须决定它是否对您的情况有用。

于 2012-11-14T12:52:32.590 回答