使用单表进行 MtM 关系的数据库设计有哪些优势？

Question

支持我们软件产品的数据库具有如下表设计：

Positions
ID    Name    Parts
1     One     12345
2     Two     12346
3     Three   12347

Collections
ID      TableID  Collection
12345   1;1      1;2
12346   1;1      3;4
12347   1;2;2    5;1;2

Parts
ID     Name
1      TestOne
2      TestTwo
3      TestThree
4      TestFour
5      TestFive

SubParts
1      SubPartOne
2      SubPartOne

从上面的例子来看，每个Position都有一个 集合Parts，但是这些都被一般地（没有外键约束）映射到Collections表中。该Collections表跟踪所有对象之间的所有关系，而不仅仅是上面显示的示例表之间的关系，并且将在使用集合的任何时候使用。

这意味着如果我想获得PositionID 为 1 的及其所有部分。我必须做三个查询：

SELECT * FROM Positions WHERE ID = 1
SELECT * FROM Collections WHERE ID = 12345

Split the string by the semicolons

SELECT * FROM Parts WHERE ID = 1 OR ID = 2

当前方法的优点是：

• 实际上可以从多个表中选择一些东西的集合。例如，如果 SubPart 继承自 Part，并且 position 包含一个 Parts 列表，这将被处理为 OK。

当前方法的缺点是：

• 速度？我们需要做很多查询来加载数据。

• 该Collections表是我们数据库中最大或第二大的表。

• ORM 框架不支持？我们正在考虑将我们的持久层切换为使用 EF 或 NHibernate 等，但我不相信我们当前的设计会得到任何这些框架的支持。

我的问题是：

• 我没有列出的这种方法有什么优点或缺点吗？

• 这个设计是否为人们所熟悉，如果是，它有名字吗？

• 如果设计很熟悉，开箱即用的 ORM 框架是否支持它？

Answer 1

我不知道这个设计有没有名字，但它是：

• 检索数据太可怕了，

• 可怕的修改，

• 无法保证参照完整性。

想不出任何优势，但如果可以的话，我相信没有人会胜过这三个。

与这种设计相比，多个多对多表会好得多，尽管我不会坚持这是唯一的选择。