2

これが特定のシナリオを処理するための最良の方法であることを確認したいと思います。

私が3つのメインテーブルを持っているとしましょう。それらを汎用的に保ちます。それらはすべて主キーを持ち、何も参照しない独立したテーブルです。

表1

PK
VarChar Data

表2

PK
VarChar Data

表3 

PK
VarChar Data

これがシナリオです。ユーザーが上記の各テーブルの特定の行にコメントできるようにしたいと思います。しかし、私はたくさんのコメントテーブルを作成したくありません。だから今のところ私はそれをそのように扱った。

それぞれが上記のメインテーブルを参照する3つの外部キー列を持つコメントテーブルがあります。これらの列の1つだけを評価できるという制約があります。

コメントテーブル 

PK 
FK to Table1
FK to Table2
FK to Table3
VarChar Comment
FK to Users

私の質問：これは状況を処理するための最良の方法ですか？一般的な外部キーは存在しますか？または、データ構造がまったく同じであっても、メインテーブルごとに個別のコメントテーブルを用意する必要がありますか？それとも、それぞれのマッピングテーブルがより良い解決策でしょうか？

4

2 に答える 2

3

すべての助けてくれてありがとう、私は私の同僚の助けを借りて解決策を策定することができました. 複数のマッピング テーブルの代わりに、1 つだけを使用することにしました。

このマッピング テーブルにはコメントのグループが保持されるため、主キーはありません。また、各グループ行はコメントにリンクしています。したがって、同じグループ ID を複数持つことができます。1 対 1 の関係になります。

データベース グループ テーブルの概念

于 2012-12-13T20:04:10.350 に答える
3

My question: is this the best way to handle the situation?

Multiple FKs with a CHECK that allows only one of them to be non-NULL is a reasonable approach, especially for relatively few tables like in this case.

The alternate approach would be to "inherit" the Table 1, 2 and 3 from a common "parent" table, then connect the comments to the parent.

Look here and here for more info.

Does a generic foreign key exist?

If you mean a FK that can "jump" from table to table, then no.

Assuming all 3 FKs are of the same type1, you could theoretically implement something similar by keeping both foreign key value and referenced table name2 and then enforcing it through a trigger, but declarative constraints should be preferred over that, even at a price of slightly more storage space.

If your DBMS fully supports "virtual" or "calculated" columns, then you could do something similar to above, but instead of having a trigger, generate 3 calculated columns based on FK value and table name. Only one of these calculated columns would be non-NULL at any given time and you could use "normal" FKs for them as you would for the physical columns.

But, all that would make sense when there are many "connectable" tables and your DBMS is not thrifty in storing NULLs. There is very little to gain when there are just 3 of them or even when there are many more than that but your DBMS spends only one bit on each NULL field.

Or should I have a separate comments table for each main table, even though the data structure would be exactly the same?

The "data structure" is not the only thing that matters. If you happen to have different constraints (e.g. a FK that applies to one of them but not the other), that would warrant separate tables even though the columns are the same.

But, I'm guessing this is not the case here.

Or would a mapping table for each one be a better solution?

I'm not exactly sure what you mean by "mapping table", but you could do something like this:

enter image description here

Unfortunately, that would allow a single comment to be connected to more than one table (or no table at all), and is in itself a complication over what you already have.

All said and done, your original solution is probably fine.

1 Or you are willing to store it as string and live with conversions, which you should be reluctant to do.

2 In practice, this would not really be a name (as in string) - it would be an integer (or enum if DBMS supports it) with one of the well-known predefined values identifying the table.

于 2012-12-12T17:37:31.400 に答える