制作通用链接表是一个坏主意吗？

Question

想象一下具有高度规范化的元数据库。如果我试图在这里描述它，它会炸毁这个输入字段。但是，想象一下，通过所有表格，整个数据库中的每个关系都会通过一个名为 link 的表格。它有以下字段： master_class_id，master_attr_id，master_obj_id，class_id2，obj_id2 。这个表可以很容易地表示各种关系：1：1,1：n，m：n，self：self。

我看到这个桌子将要获得HUUUUGE的问题。这是不好的做法吗？

Answer 1

这两个帐户都错了：

1. 这对您的所有查询都是一个巨大的瓶颈，它会扼杀任何吞吐量。

2. 糟糕的设计：你应该能够更简洁，更接近现实来描述事物。如果这确实是存储数据的最佳方式，您可以考虑分区甚至是另一种范例而不是关系

Answer 2

总之，是，这是一个坏主意

如果没有太多细节，我会提供以下内容：

• 对于元数据库，链接表应该由（高级）实体拆分：也就是说，每个实体应该有一个单独的链接表
• 实体间链接需要另一个链接表

通常，高级实体很容易识别，例如客户。

Answer 3

这通常是不好的做法，但不是因为桌子很大。问题是你在一个表中混合不相关的数据。

将链接保留在单独的表中的原因是因为您不需要一起使用它们。

这也是数据本身的一个常见错误：您不应该只在一个表中混合两组数据，因为如果数据本身不相关，则字段相似。

Answer 4

关系数据库实际上并不适合此模型。

可以实现它，但速度很慢。主要缺点是您无法有效地索引链接。

但是，这种设计在两种情况下很有用：

1. 这只存储元数据：实体之间声明的关系。实际数据存储在普通关系表中，因此此链接仅用于显示结构，但不用于实际查询。

2. 这会存储一些复杂但数据很少的结构，因此易于开发会超出性能缺陷。

这个设计可以在几个ORM中看到（其中一个我甚至开发过）。

Answer 5

无论如何，我没有看到这种类型表的目的。如果表A对表B是一对多，那么A仍然会有PK而B仍然会有PK。 A通常包含FK到B。

所以在Master_Table中你必须存储A PK，B FK，这只是已经存在的重复。您将“失去”的唯一事情是表A中的FK，但您只是将其迁移到一个巨大的表中，数据库，dba以及任何使用数据库编码的人都难以处理。

这些表最常出现在Access中，并显示在DailyWTF上，因为它们非常难以阅读和理解。

哦！一个主要的问题是，为了使表无处不在，你将不得不制作通用列，最终可能会破坏数据的完整性。