スレッド化されたコメントを支援するために、アプリケーションでPostgreSQL のLtree モジュールを使用することを検討しています。スレッド化されたコメントに使用するためにしばらく注目していました。コメントとその返信を非表示にする場合など、ノードとその子を更新する必要がある場合に役立つと思います。
ltree (またはそれに似たもの) を従来の隣接リスト ("comment_id"/"parent_comment_id") と組み合わせると便利だと思います。
ltree の使用に飛び込む前に、いくつか疑問に思っていることがあります。
- ltree を使用していますか、または使用したことがありますか? それは「生産準備完了」と呼ばれるものですか?
- もしそうなら、それを使ってどのような問題を解決しましたか? うまくいきましたか?
- スレッド化されたコメント システムに適していると思いますか?
- 使用した場合、パスの「テキスト」部分には何を使用しましたか? 「Top.Astronomy.Cosmology」を使用する DMOZ の例のようなものを設定しましたか、それとも主キー「1.403.29.5」のようなものに基づいていますか?
- これを行うより良い方法はありますか?ネストされたリストのアプローチを使用するのは少し緊張しています-私が読んだすべてのことは、UPDATESまたはINSERTSですべてがホットではないことを示唆しています(すべてを並べ替える必要はありませんか?)。私も CS 専攻ではありません。そのようなデータ構造は、将来忘れてしまうかもしれません。ネストされたリストをコメントなどに使用している人はいますか?
参考になれば、私が検討しているスキーマは次のとおりです。
CREATE TABLE comments (
comment_id SERIAL PRIMARY KEY,
parent_comment_id int REFERENCES comments(comment_id) ON UPDATE CASCADE ON DELETE CASCADE,
thread_id int NOT NULL REFERENCES threads(thread_id) ON UPDATE CASCADE ON DELETE CASCADE,
path ltree NOT NULL,
comment_body text NOT NULL,
hide boolean not null default false
);
ltree で使用される「パス」列は、次のようになります。
<thread_id>.<parent_comment_id_#1>.<parent_comment_id_#2>.<my_comment_id>
パスで主キーを使用することに問題はありますか? ノード自身の主キーをパスに含める必要がありますか? もしそうなら、制約として機能する一意のインデックスを配置することは理にかなっていますか?