ピボットテーブルと1-Many関係のParent_ID

Question

一般的な一対多（親から子）の関係では、（a）子テーブルにparent_idを置くことと、（b） parent_id、child_idのみのピボットテーブル？

注：必要に応じてOracleを使用し、そうでない場合は一般的なRDBMSを使用して回答します。

Answer 1

PIVOTテーブルでは、many-to-manyというリンクテーブルを意味する場合は、パフォーマンスが低下するだけです。

子テーブルにparent_idを保存する必要があります。

many-to-manyリンクテーブルは余分にJOINを要し、効率が悪いです。

は、次のクエリの比較：

SELECT * 
FROM child_table c 
JOIN child_to_parent cp 
ON  cp.child = c.id 
JOIN parent p 
ON  p.id = cp.parent 
WHERE c.property = 'some_property' 

と、この1：

SELECT * 
FROM child_table c 
JOIN parent p 
ON  p.id = c.parent 
WHERE c.property = 'some_property' 

後者は1 JOIN短く、より効率的です。

SELECT * 
FROM child_table c 
JOIN parent_table p 
ON  p.id = c.parent 
WHERE c.id IN (id1, id2, ...) 

を、私：あなたは、多くの場合、これらのクエリを実行することを

そのルールの唯一の可能な例外はあります。 e。あらかじめ子の行のidを知っています。

これは、child_tableにナチュラルキーを使用する場合に便利です。この場合

はい、child_to_parentリンクテーブルは、あなただけの次のクエリでそれを置き換えることができるので、より効率的になります。

SELECT * 
FROM child_to_parent cp 
JOIN parent_table p 
ON  p.id = cp.parent 
WHERE cp.child IN (id1, id2, ...) 

とchild_to_parentがchild_tableに必ず以下のサイズでなり、より効率的です。

しかし、Oracleでは、child_table (id, parent_id)に複合インデックスを作成しても同じ結果が得られます。

はインデックスNULLのインデックスではないため、このインデックスはchild_to_parentテーブルと似ていますが、テーブル自体はなく、メンテナンスのオーバーヘッドも含まれません。他のシステム（インデックスNULL年代）では

、インデックスはあなたがNULL両親の多くを持っている場合は特に、専用のテーブルよりも少ない効率的な場合があります。