2

そのようなことを実現できますか?たとえば、他のフィールド値が「a」の場合、外部キーはテーブルaに対するものである必要があり、値が「b」の場合、それはテーブルbに対するキーである必要がありますか?これは正常ではなく、外部キーの考え方と一致しないことは理解していますが、実際にこのスキームを実現するために何かを行うことは可能ですか?

アップデート :

私はこのようなスキーマを持っています:

商品があります。さまざまな追加フィールドを含めることができます。たとえば、標準製品には追加フィールドを含めることはできませんが、「画像」には「作成者」などのフィールドを含めることができます。本当に「標準的な製品」と「絵」は、追加のフィールドのためだけでなく、イデオロギー的に異なる可能性があります。

「注文」のようなテーブルがあり、製品やその他のデータへのリンクが含まれている必要があります。しかし、「製品ID」のようなフィールドを入力すると、データである必要があります。それは、標準の製品IDであるか、画像IDであるかです。

追加フィールドのテーブルのようなデザインもあり得ますが、別の問題があります。table(id、additional_field_name)とマッピング用のtable(id、add_field_id、product_id、field_value)を作成できますが、field_valueは数値でも文字列でもかまいません。したがって、このアイデアは適切ではないと思います。

4

3 に答える 3

2

述べたように、あなたはそれをすることはできません。2つの別々の列が必要になります。その上、別の列の値に基づいて列の値を解釈することは、私には正しく感じられません。

于 2013-02-01T17:48:56.317 に答える
0

あなたのコメントと改訂された質問によると:

製品

ID
Description
AdditionalFields_ID

追加フィールド

AdditionalFields_ID
Author

次に、LEFT JOINを使用して、クエリが追加のフィールドが存在する場合にのみプルするようにします(製品タイプが画像の場合など)。

SELECT *
FROM Products P LEFT JOIN AdditionalFields A ON P.AdditionalFields_ID = A.AdditionalFields_ID

それよりも良い答えが必要な場合は、質問のテーブル構造とデータの実際の例をいくつか提供する必要があります。

于 2013-02-01T18:03:10.147 に答える
0

外部キー制約の場合、潜在的な外部キー関係ごとに1つずつ、個別のnull許容列を使用する必要があります。

これをチェック制約と一緒にハックすることもできますが、パフォーマンスの観点と一貫性の観点の両方から、別々の列を使用する方がよいでしょう。

于 2013-02-01T17:54:39.820 に答える