子孫についても、同じように取得してみよう。連なるすべての親を取得してみよう。そのレコードになっているものから引っ張ってくればいい。sec)挿入するコメントを追加するときは、最初にやったのと同じようにすべての先祖に自身を登録していけばいい。sec)上記でツリーはこんな感じになる。削除する次は閉包テーブルモデルにおいて、コメントを削除するときのことを考えてみよう。削除するコメントが末端のレコードであれば話はとても単純になる。して持っている親子関係のレコードと、コメント本体を削除すれば良いだけだから。sec)これで、ツリーは元の状態に戻った。末端でないコメントを子孫ごと削除しようとすると少し考えることが増える。コメントを子孫ごと削除することを考えてみることにしよう。参照しているレコードを確認する。持ったレコードは親子関係のテーブルにおいて先祖からも参照されているということに注意しなければいけない。して持つレコードを引いてこよう。sec)これが実際に削除すべき親子関係のレコードということになる。標準的な制約が原因となっている。あるテーブルに変更を加える場合、同じテーブルはサブクエリに含めることができないためだ。いったときは、サブクエリに別名をつけて回避する。いう名前をつけている。すれば先ほどの制約に引っかかることがない。sec)検索できる内容は、もちろんおんなじ。したときエラーにならずレコードが削除できる。sec)めでたしめでたし、と行きたいところだけど、まだコメント本体が残っている。ツリー的には、こういう状態だ。親子関係は先ほど既に削除してしまったので、それを元に削除はできない。実際のところ、閉包テーブルモデルでは親子関係のレコードを削除しただけで済ませるときもあるみたいだ。ようするに、親子関係のテーブルでどこからも参照されていないコメントのこと。必然的に、さっき親子関係を削除したものが対象になる。sec)これらを削除して一丁上がり。sec)孤児になったレコードがなくなったので、ツリーの状態はこうなる。アンチパターン「ナイーブツリー」の解決策のひとつとして閉包テーブルモデルについて扱った。閉包テーブルモデルの特徴は次の通り。メリット親子関係を外部キー制約を使って表現するので、整合性がリレーショナル・データベースとして担保できる。検索や挿入などが少ないクエリで済む。階層の深さに明確な限界がない。デメリット階層が深くなるごとに、それを表現するためのレコードが増えていく。たくさんのデータを扱うことになってディスクの容量を圧迫する。試した環境は次の通り。ビルドする注目記事スポンサードリンクスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。