3

我遇到了一些人称之为相当奇怪的问题/问题。

假设我有一个表，它可能引用许多不同的其他表中的一个（并且只有一个）。我将如何以最好的方式做到这一点？我正在寻找一种适用于大多数数据库（MS SQL、MySQL、PostgreSQL 等）的解决方案。在我看来，有几种不同的解决方案（比另一个更好吗？）：

  1. 为每个可能的参考设置一列。这些列中只有一个可能包含任何给定行的值，所有其他列都为空。允许严格的外键，但是当“许多”（可能引用的表）的数量变大时会变得乏味
  2. 具有两列关系，即一列“描述”引用哪个表，一列引用实​​例（该表中的行）。当“许多”（引用表）的数量增加时，可以轻松扩展，尽管我不能以直接的方式执行单个查询查找（左连接所有可能的表，或者联合多个查询，每个查询连接一个表）
  3. ??

说得通？在这种情况下，最佳做法（如果有）是什么？我特别希望能够从被引用的实体中查询数据，而无需真正知道正在引用哪些表。

你会怎么做？

4

2 回答 2

2

Both of these methods are suitable in any relational database, so you don't have to worry about that consideration. Both result in rather cumbersome queries. For the first method:

select . . .
from t left outer join
     ref1
     on t.ref1id = ref1.ref1id left outer join
     ref2
     on t.ref2id = ref2.ref2id . . .

For the second method:

select . . .
from t left outer join
     ref1
     on t.anyid = ref1.ref1id and anytype = 'ref1' left outer join
     ref2
     on t.anyid = ref2.ref2id and anytype = 'ref2' . . .

So, from the perspective of query simplicity, I don't see a major advantage for one versus the other. The second version has a small disadvantage -- when writing queries, you have to remember what the name is for the join. This might get lost over time. (Of course, you can use constraints or triggers to ensure that only a fixed set of values make it into the column.)

From the perspective of query performance, the first version has a major advantage. You can identify the column as a foreign key and the database can keep statistics on it. This can help the database choose the right join algorithm, for instance. The second method does not readily offer this possibility.

From the perspective of data size, the first version requires storing the id for each of the possible values. The second is more compact. From the perspective of maintainability, the first is hard to add a new object type; the second is easy.

If you have a set of things that are similar to each other, then you can consider storing them in a single table. Attributes that are not appropriate can be NULLed out. You can even create views for the different flavors of the thing. One table may or may not be an option.

In other words, there is no right answer to this question. As with many aspects of database design, it depends on how the data is going to be used. Absent other information, I would probably first try to coerce the data into a single table. If that is just not reasonable, I would go with the first option if the number of tables can be counted on one hand, and the second if there are more tables.

于 2013-04-22T21:43:19.777 回答
1

1)

这对于少量静态表是合法的。如果您预计将来可能需要添加许多新表，请查看下面的3) ...

2)

请不要那样做。您将丧失声明性 FOREIGN KEY，这是维护数据完整性的最重要机制之一。

3)

使用继承。这篇文章中的更多信息：

您可能还有兴趣查看：

于 2013-04-22T21:47:33.970 回答