記事コメント (NetEase ニュース コメントの形式) をネストして表示するための mysql テーブル構造を設計する方法

投稿テーブルができました (構造は変更できません)
tid トピック pid
pid 返信 ID

新たにコメントの入れ子表示機能が追加されました。つまり、 tid=1
aがpid1のコメントにコメント
bがpid2のaのコメントに返信
cがpid3のbのコメントに返信
d は a に 3 4 の pid で返信しました

1 階 pid1
2 階 pid1、pid2
3 階 pid1、pid2、pid3
4 階 pid1、pid4 として表示されます。
つまり、他の人へのすべての返信は、以前のすべての返信を引用する必要があります。
(NetEase Newsのコメントと同じ形式です)
今考えている構造は、post_conversation pid, to_pid
このように、2階の返信には2,1が挿入されます
リーリー

99階で会話がある場合は98個のデータを入れる必要があります

リーリー

post_conversation が次のように設計されている場合

pid、parent_pid (返信される pid)
データ量は少ない (返信ごとに 1 つのメッセージのみが挿入される)
しかし、各 pid についてすべての会話をクエリするのは非常に面倒です (私はそうです)。再帰クエリ データベースについて考えています);
リーリー

何か良い提案はありますか？

返信内容:

投稿テーブルができました (構造は変更できません)

tid トピック pid

pid 返信 ID

新たにコメントの入れ子表示機能が追加されました。つまり、 tid=1

aがpid1のコメントにコメント

bがpid2のaのコメントに返信
cがpid3のbのコメントに返信
d は a に 3 4 の pid で返信しました

1 階 pid1

2 階 pid1、pid2

3 階 pid1、pid2、pid3
4 階 pid1、pid4 として表示されます。
つまり、他の人へのすべての返信は、以前のすべての返信を引用する必要があります。
(NetEase Newsのコメントと同じ形式です)
今考えている構造は、post_conversation pid, to_pid
このように、2階の返信には2,1が挿入されます
リーリー
99階で会話がある場合は98個のデータを入れる必要があります
リーリー

post_conversation が次のように設計されている場合

pid、parent_pid (返信される pid)

データ量は少ない (返信ごとに 1 つのメッセージのみが挿入される)

ただし、各 pid についてすべての会話をクエリするのは非常に面倒です (私はそうです)。再帰クエリ データベースについて考えています);
リーリー
何か良い提案はありますか？

ご招待ありがとうございます

私は、無限のネスト (メニュー、コメント) を実現するために、最も原始的な再帰クエリ方法を使用していました。その後、管理者が Laravel-China コミュニティに投稿した記事を見ました。記事のアドレスは https://laravel-china.org/topics/2124 で、

を使用して無限ツリー状の階層モデル (タグ システム、メニューシステム、コメントシステムなど）。件名は以下を参照できます。

「コメントの引用」は実装に比較的コストがかかり、冗長性が高いため、代わりに「コメントへの返信」を使用することを検討できます。 预排序遍历树算法(Nested set model) 1 つの記事が複数のコメントに対応し、1 つのコメントが複数の返信に対応します。

Q&A コミュニティsegmentfault.com。

セグメントフォールトを例に挙げます。

質問者 (投稿者) が質問を投稿し、この質問には複数の回答 (レイヤー所有者) があり、これは 1 対多の関係になります。データベース。
各回答には複数の返信を含めることができ、これも 1 対多の関係になります。
リーリー