まえがき
２章 Naive Trees(素朴な木) を参考に自分のポートフォリオを見直してみました。
RDBにおけるデータ構造
RDBにおけるデータ構造には大きく分けて４つあります。
①隣接リストモデル（ナイーブツリー）
②経路列挙モデル
③閉包テーブルモデル
④入れ子集合モデル
素朴な木とは？
素朴な木とは、①の隣接リストモデルに該当します。
例
隣接リストモデルとは、最も単純な構造で以下のようなテーブルとなります。
特徴は、それぞれの要素が自分の親だけを知っていることです。
| id | name | parent_id |
|---|---|---|
| 1 | 地名 | NULL |
| 2 | 日本 | 1 |
| 3 | アメリカ | 1 |
| 4 | 東京 | 2 |
| 5 | 大阪 | 2 |
| 6 | 渋谷 | 4 |
| 7 | 吹田 | 5 |
| 8 | 品川 | 4 |
| 9 | ニューヨーク | 3 |
| 10 | ナイアガラ | 9 |
| 11 | ロサンゼルス | 3 |
メリット、デメリット
-
メリット
- 単純な構造で理解しやすい
-
デメリット
- 階層が決まっていない場合の取得が困難
(日本に関する子孫ツリーの数を取得しようとするのが困難になる)
- 階層が決まっていない場合の取得が困難
現状の構造
コメントをスレッド形式で表示する機能にて、
「コメント」、「コメントに対する返信」も両方Commentsテーブルに格納されています。
| comment_id | content | reply_comment |
|---|---|---|
| 1 | 朝ごはんを食べました | NULL |
| 2 | 早起きしました | NULL |
| 3 | 何食べたの？ | 1 |
| 4 | 今日は出かけます | NULL |
| 5 | 僕も食べました！ | 1 |
| (reply_commentはどのコメントに対する返信かを表しています) |
今回のパターンでは、
階層は2階層で固定
の構造なので、デメリットの部分を意識する必要はなく隣接リストモデルでも問題ないのかなと思います。
改善するなら
今後、改善としてスレッド内でさらにどのコメントに対するコメントかを細かく分類したい場合は、隣接リストモデルでは不十分だと考えられます。
その際は、閉包テーブルモデルを採用しテーブルを二つに分ける必要が出てきます。