SQLアンチパターン - ナイーブツリー

ナイーブツリー

SQLアンチパターンその2 素朴な木

ナイーブツリー is

直近の親のみを参照する事でツリー構造を表現する SQLアンチパターン

シナリオ

A「ブログのコメント欄さ」

B「はい」

A「よく議論やってるじゃん？」

B「ですね」

A「スレッド形式で表示できたら分かりやすいと思うんよね」

B「考えてみます」

シナリオ

B「今のテーブル定義こんな感じだから」

id comment

1 たけのこ派駆逐したい

2 きのこ派怖いわー

3 >>1 同意

4 >>2 たけのこ汚い

たけのこ派駆逐したい

きのこ派怖いわー

>>1 同意

>>2 たけのこ汚い

シナリオ

B「コメント間に親子関係があればいいわけで」

id comment



3 >>1 同意




>>1 同意


シナリオ

B「こうすればいいか」

id parent comment

1 null たけのこ派駆逐したい

2 1 きのこ派怖いわー

3 1 >>1 同意

4 2 >>2 たけのこ汚い



>>1 同意


シナリオ

B「こうすればいいか」

id parent comment

1 null たけのこ派駆逐したい

2 1 きのこ派怖いわー

3 1 >>1 同意

4 2 >>2 たけのこ汚い



>>1 同意


素朴な木

ナイーブツリー

Bの主張

葉の追加も簡単だし参照整合性も維持できるし最強に見える。

Bの主張

葉の追加も簡単だし参照整合性も維持できるし最強に見える。

ツリーの参照は？

コメント数の数えるとか集約系の関数は？

非葉ノードの削除は？サブツリーの昇格は？

ナイーブツリー選択のデメリット

(サブ)ツリーを引っこ抜けない

ツリー全体

あるいはあるコメントのサブツリー



ツリー全体


たけのこ派駆逐したい select

c1.* from comm c1



ツリー全体




select c1.*, c2.* from comm c1 left outer join comm c2 on c1.id = c2.parent コメント1を親に持つコメント



ツリー全体





select c1.*, c2.*, c3.* from comm c1 left outer join comm c2 on c1.id = c2.parent left outer join comm c3 on c2.id = c3.parent コメント1を親に持つコメント

を親に持つコメント



ツリー全体


n階層取得したい場合は…？

子が存在し続ける限り自動でjoinし続けてくれるSQLは書けない

取得できる階層が固定される

必然的にある任意の(サブ)ツリーのコメント総数みたいな集約関数も使えない


非葉ノードとそのサブツリーの削除

コメント1削除

コメント1を親に持つコメントを削除

…とやりたいけど参照整合性のため子から削除する必要がある

c1、c1を親に持つ(c2)、c2を親に持つ…を結果が返らなくなるまで繰り返して削除対象のコメントを取得し、子側からdeleteしないとダメ

とは言えdelete on cascadeが使えれば、これは自動化出来る








select

select






select

select

select





select

select

delete




delete



delete


非葉ノード削除とそのサブツリーの昇格

非葉ノードにくっついていたサブツリーを自分の親の子へ昇格させる場合

こちらはdelete on cascadeズパーンとはいかない

削除前に自分の子を取得し、子の親を自分の親へ付け替えた上で削除する必要がある





>>1 同意


←削除したい





>>1 同意


←削除したい

←子の親を





>>1 同意


←削除したい

←自分の親へ更新




>>1 同意


←削除




>>1 同意



まとめ

再帰的にクエリ吐けるとかじゃなきゃやってられない

サブツリー一括の削除や移動はまだしもノードの昇格とかちょっと凝った操作を実現するのはつらい。

B「僕は…どうしたらよかったんだ…」

解決策

代替ツリーモデルを使いましょう

ツリーを表現する他の方法

経路列挙モデル

入れ子集合モデル

閉包テーブルモデル

解決策 : 経路列挙モデル

id path comment

1 1/ たけのこ派駆逐したい

2 1/2 きのこ派怖いわー

3 1/3 >>1 同意

4 1/2/4 >>2 たけのこ汚い

たけのこ駆逐したい

>>1 同意きのこ派怖いわー



メリットサブツリーの一括取得ができる

likeを用いたパターンマッチ path like ‘1/2/%’

ノードの追加は親ノードのpathにidを連結したpath文字列で追加する

葉ノードの削除はdeleteするだけ

デメリット >突然のジェイウォーク！< 長さ制限とか参照整合性とか同様の脆弱性非葉ノードの削除、サブツリーの昇格とか移動とかは子のpathを全て更新しないといけないので隣接ツリーよりだるい


id path comment



3 1/3 >>1 同意

4 1/2/4 >>2 たけのこ汚い




2に子を追加


id path comment



3 1/3 >>1 同意

4 1/2/4 >>2 たけのこ汚い

5 1/2/5 きのこfudやめろたけのこ駆逐したい


>>2 たけのこ汚いきのこfudやめろ


id path comment



3 1/3 >>1 同意

4 1/2/4 >>2 たけのこ汚い

5 1/2/5 きのこfudやめろたけのこ駆逐したい


>>2 たけのこ汚いきのこfudやめろ

path like ‘1/2%’でサブツリーを選択できる。

解決策 : 入れ子集合モデル

id left right comment

1 1 8 たけのこ派駆逐したい

2 2 5 きのこ派怖いわー

3 6 7 >>1 同意

4 3 4 >>2 たけのこ汚い




1

2

3

6

4

8

7 5


Left? Right? Left : その子ノードの持つどのLR値よりも小さい値

Right: その子ノードの持つどのLR値よりも大きな値

深さ優先探索で求まる

メリット子孫、先祖ノードの一括取得ができる

ノードを削除すると自動的に子ノードが親ノードの子へ昇格する

デメリットノードの追加や更新(移動)が複雑過ぎる

LR値の再計算が必要

隣接リストでは簡単な直近の子の取得がだるい





1





1

2





1

2

3





1

2

3 4





1

2

3 4

5





1

2

3

6

4

5





1

2

3

6

4

7 5





1

2

3

6

4

8

7 5





1

2

3

6

4

8

7 5

サブツリーのどのLR値より小さい





1

2

3

6

4

8

7 5

サブツリーのどのLR値より大きい





1

2

3

6

4

8

7 5

1の子孫ツリーの取得 →L値が1～8のコメント





1

2

3

6

4

8

7 5

1の子孫ツリーの取得 →L値が1～8のコメント





1

2

3

6

4

8

7 5

4の先祖ツリーの取得 →L <= 3 <= R を満たすコメント





1

2

3

6

4

8

7 5

4の先祖ツリーの取得 →L <= 3 <= R を満たすコメント





1

2

3

6

4

8

7 5

2にノードを追加





1

2

3

6

4

8

7 5


きのこfudやめろ

5 6

↑ L:R = 5:6を追加したい

さっきの深さ優先探索より 2:5の子に追加するのでこのノードのLR値は5:6になるはず (親のノードのR値を追加しようとするノードのL値にする)





1

2

3

6

4

8

7 5



5 6

↑ 追加されたノード以降のLR値を再計算(+2する)





1

2

3

8

4

10

9 7



5 6





1

2

3

8

4

10

9 7



5 6

↑ 追加

解決策 : 閉包テーブルモデル

id comment



3 >>1 同意





先祖子孫

1 1

1 2

1 4

1 3

2 2

2 4

3 3

4 4


ノード同士の関係性を定義するテーブルを追加する直近の親子関係だけじゃなく、全体のパスを持つ

離れたノードの親子関係も自分自身を参照するパスも含める

メリットツリーの取得、移動、ツリーの削除、ツリーの昇格、マルチルート、複数の親への所属などとにかく柔軟

入れ子集合ほどは複雑じゃない

デメリット柔軟過ぎる入れ子ほどじゃないと言うだけでそこそこ複雑パステーブルのデータ量が激ふえする


node

A

B

C

D

A

C B

D

先祖子孫


node

A

B

C

D

A

C B

D

先祖子孫

A A


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D

B B


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D

B B

B D


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D

B B

B D

C C


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D

B B

B D

C C

D D


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D

B B

B D

C C

D D 直近だけでなく全てのノードの親子関係を定義パステーブルの1行は上図の矢印1本に相当する


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D

B B

B D

C C

D D Aの子孫ツリー →Aを先祖として持つ子孫


node

A

B

C

D

A

C B

D

先祖子孫

A A

A B

A C

A D

B B

B D

C C

D D Dの先祖ツリー →Dを子孫として持つ先祖


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A B

A C

A D

B B

B D

C C

D D Bの子としてEを追加 →自己参照追加 →Bを子孫として持つ先祖の子孫にEを追加

E

E E

A E

B E


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A B

A C

A D

A E

B B

B D

B E

C C

D D

E E Bの子としてEを追加 →自己参照追加 →Bを子孫として持つ先祖の子孫にEを追加

E


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A B

A C

A D

A E

B B

B D

B E

C C

D D

E E Bのツリーをまるごと削除 →Bを子孫とする関係を削除

E


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A B

A C

A D

A E

B B

B D

B E

C C

D D

E E Bのツリーをまるごと削除 →Bを子孫とする関係を削除 →Bの子孫を子孫とする関係を削除 (Bを先祖とするノードを子孫として持つ関係)

E


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A C

C C

Bのツリーをまるごと削除 →Bを子孫とする関係を削除 →Bの子孫を子孫とする関係を削除 (Bを先祖とするノードを子孫として持つ関係)

E


node

A

B

C

D

E

Bを削除 →Bを子孫とする関係を削除

先祖子孫

A A

A B

A C

A D

A E

B B

B D

B E

C C

D D

E E

A

C B

D E


node

A

B

C

D

E

Bを削除 →Bを子孫とする関係を削除 →Bを先祖とする関係を削除

先祖子孫

A A

A B

A C

A D

A E

B B

B D

B E

C C

D D

E E

A

C B

D E


node

A

B

C

D

E

Bを削除 → C, Eが自動的にAの子に昇格 →Bを子孫とする関係を削除 →Bを先祖とする関係を削除

先祖子孫

A A

A C

A D

A E

C C

D D

E E

A

C B

D E


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A B

A C

A D

A E

B B

B D

B E

C C

D D

E E

BをCの子へ移動 →Bを子孫とする関係と Bの先祖からBの子孫への関係を削除 (ただし自己参照を除く)

E


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A C

B B

B D

B E

C C

D D

E E

BをCの子へ移動 →Bを子孫とする関係と Bの先祖からBの子孫への関係を削除 (ただし自己参照を除く)

E


node

A

B

C

D

E

A

C B

D

先祖子孫

A A

A C

B B

B D

B E

C C

D D

E E

BをCの子へ移動 →Cを子孫とする移動先サブツリーから孤立中のBのツリーのノードへの全経路を cross joinで生成する

E

A B

A D

A E

C B

C D

C E


node

A

B

C

D

E

A

C

B

D

先祖子孫

A A

A B

A C

A D

A E

B B

B D

B E

C B

C C

C D

C E

BをCの子へ移動 E

D D

E E

まとめ

隣接リストシンプルツリー取得、操作が苦手

経路列挙シンプルかつツリー取得可能ジェイウォーク

入れ子集合子孫、先祖ツリーの取得が可能ノードの削除で子ノードが自動で昇格するツリー操作が死ぬほど複雑

閉包テーブル入れ子集合に比べれば(比べればと言う程度)シンプル先祖、子孫の取得、サブツリーごと削除、子の昇格、ツリー移動な

ど大体の事が出来るその代わりツリー構造管理テーブルが必要パステーブルのデータ量がめっちゃ増える

ナイーブツリー(素朴な木)

ツリー表現の解決策としては素朴過ぎると言う意味

素朴故に多用される。

ただし常にナイーブツリー is 悪ではない

ツリーを表現する手法は他にもあるんだよ、ということを覚えておきましょう

アンチパターンを用いていい場合

隣接リストでアプリの要件を満たせる場合

実際シンプル

その他の手法(特に入れ子集合)はそれなりの複雑さを持ち込むことになる

複雑さ is バグの元

利用DB製品が再帰クエリ構文をサポートする場合

ぽすぐれ、SQLServer、Oracle、DB2

再帰クエリなら隣接リストでもツリー取得可

おわり

Technology

SQLアンチパターン - ナイーブツリー