此问题在此处已有答案：
How can you represent inheritance in a database? [closed]（7个答案）
26天前关闭。
我有一个用于维护D&D游戏的SQL数据库，其中包含角色，物品和位置等表格。我想开始建模所有这些不同实体类型之间的关系，例如角色与另一个角色的关系，或者角色与特定物品或位置的关系，本质上是创建一个游戏中所有内容如何链接在一起的图表。
我最初尝试的是从Character关系的Angular 出发，创建一个多对多的连接表，如下所示：
CREATE TABLE character_relationships (
character_id_from UUID REFERENCES characters(id),
character_id_from_id_to UUID REFERENCES characters(id),
relationship_type TEXT,
opinion TEXT,
-- Additional relationship-specific attributes
);字符串
但是如果我希望能够对任何实体类型的关系进行一般建模，比如字符到项目，或者项目到位置，那么处理这个问题的最佳方法是什么呢？
我想我可能需要创建一个名为Entity的“超类”表，它首先被插入到中以检索ID，然后用于插入到子类Characters，Items和Locations表中，结果是这样的连接表：
CREATE TABLE entity_relationships (
entity_id_from UUID REFERENCES entities(id),
entity_id_from_id_to UUID REFERENCES entities(id),
relationship_type TEXT,
opinion TEXT,
-- Additional relationship-specific attributes
);型
这是设计通用关系的最佳方法吗？或者除了为每个关系类型创建多个表之外，还有其他方法吗？这样做的潜在缺点是什么？
3条答案
按热度按时间7dl7o3gd1#
但是如果我希望能够对任何实体类型的关系进行一般建模，比如字符到项目，或者项目到位置，那么处理这个问题的最佳方法是什么呢？
如果你不需要的话，不要去 * 更高级别 *，保持具体：只为每一个这样的关系创建一个“连接表”。语义保持直接和清晰（你可以看到实际上有什么实体），你的查询也保持简单和中肯，定义约束也保持直接。
我想我可能需要创建一个名为Entity的“超类”表，[.]这样做的潜在缺点是什么？
缺点是，这与上面的情况相反，它在所有级别上都非常复杂，实际上，通常负责DBMS的大多数逻辑都必须手动编码，直到使用触发器来确保关系的一致性（以确保relationship_type与所引用的实体兼容，等等）。因此，除非域确实有一个实体类型的 open 集合，否则这根本不是一条路。
68de4m5k2#
另一种选择，有它自己的优点和缺点......“最好的”是一个很难量化的词......看到和做这个问题的很多方式有很多原因。
一个单独的连接表，使用相关实体的复合键... thing 1，thing 2，relationship_type，opinion...（不像超类Entity那样抽象）
其中thing 1和thing 2是复合键，如“person：{guid}”或“item：{guid}”或“location：{guid}”。
缺点：正如上面JDE的回答中提到的，您的代码承担了维护连接表的工作。
5hcedyr03#
首先，我质疑任何事物都可以与任何事物有关系的观念。
最简单的方法是在可能有关系的实体之间定义标准关联表。还要注意，这种方法允许您将有意义的关联数据附加到该关系中-这在一般情况下是非常尴尬的。
如果所有主键都有uuid，并且只有一个关联表，你可以用通用的方法来实现它。虽然没有定义合适的外键关系，但它还是可以工作的。但我不推荐这样做。
小的最初的努力花在做它的正常方式将得到回报很多倍以上时相比，试图弯曲数据库，以您的心血来潮。