Q&A掲示板で質問と回答と返信を識別するにはどちらの方法が良いでしょうか？

Question

実現したいこと

Q&A掲示板の質問と回答と回答に対する返信を両用データベースで作成したいと考えております。

発生している問題・分からないこと

➀、➁のどちらが適しているかアドバイスお願い致します。

※➀、➁両方に共通する処理
どの質問に対しての回答なのか紐づけのために質問ＩＤ（親ＩＤ）を設定する。

方法➀
識別用のカラムを持たせる方法で質問を「1」、回答を「2」のように意味付けて識別する。

方法②
親ＩＤが NULL（紐づけられていない）のものを質問として、親ＩＤが設定されているものを回答とする。

該当のソースコード

特になし

試したこと・調べたこと

• teratailやGoogle等で検索した
• ソースコードを自分なりに変更した
• 知人に聞いた
• その他

上記の詳細・結果

方法②の両用テーブルでのプログラム処理は下記のようになると予測しております。
回答に対する返信機能も付けたい場合、この方法は適していないのではないかと考えました。
回答ＩＤで判断する場合2択しかなく3つめの選択肢がないからです。

※質問か回答かの判断について
質問回答テーブルを質問ＩＤで参照しそのデータが質問であれば質問の出力を編集、そのデータが回答であれば回答の出力を編集。質問と回答を合わせて１件以上のループ処理。
質問：回答ＩＤがＮＵＬＬである
回答：回答ＩＤがＮＵＬＬでない

補足

特になし

Answer 1

前の質問で、「回答にさらに回答が付くことがある」というような話だったようなので、2一択ではないかと思います。

また、そのようにするのであれば「質問」と「回答」というような意味付けをやめて、メッセージはメッセージとして、単なるそれらの前後関係とか親子関係のようにとらえて属性付けして管理していくのがいいのではないかと思います。そうした場合、前(親)が無いものが原始(root)のメッセージというような考えかたになるでしょう。

Comments

[homepage-site]

TakaiYさんアドバイスありがとうございます、方法➀で考えていたのですが方法➁の方がいいんですね。
親子関係でテーブルを考えてみます。

Answer 2

テーブル構成としては②で良くて、親IDを利用した自己結合が必要になってくるはずです。

何段階でも返信ができるようにするのであれば、WITH RECURSIVE をつかった結合を利用すると
一度にデータを抽出できます。
ただSQLとしてはちょっとややこしくなるので、返信できる深さの上限を決めて複数回のSELECTを行う、でも良いとは思います。

テーブルの例

CREATE TABLE messages (
    id INT AUTO_INCREMENT PRIMARY KEY,
    parent_id INT NULL,
    content TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (parent_id) REFERENCES messages(id)
);

INSERT INTO messages (id, parent_id, content) VALUES (1, NULL, 'これは親メッセージです');
INSERT INTO messages (id, parent_id, content) VALUES (2, 1, 'これは親メッセージへの返信です');
INSERT INTO messages (id, parent_id, content) VALUES (3, 1, '親メッセージへの別の返信です');
INSERT INTO messages (id, parent_id, content) VALUES (4, 2, 'これは最初の返信への返信です');
INSERT INTO messages (id, parent_id, content) VALUES (5, NULL, 'これは別の親メッセージです');
INSERT INTO messages (id, parent_id, content) VALUES (6, 5, '2つ目の親メッセージへの返信です');
INSERT INTO messages (id, parent_id, content) VALUES (7, 6, '2つ目の親メッセージの返信への返信です');

SELECTの例

WITH RECURSIVE threads AS (
    SELECT 
        id,
        parent_id,
        content,
        created_at,
        id AS top_id,
        CAST(id AS CHAR(255)) AS path,
        0 AS depth
    FROM messages
    WHERE parent_id IS NULL

    UNION ALL
    SELECT 
        m.id,
        m.parent_id,
        m.content,
        m.created_at,
        t.top_id,
        CONCAT(t.path, '-', m.id) AS path,
        t.depth + 1 AS depth
    FROM messages m
    INNER JOIN threads t ON m.parent_id = t.id
)
SELECT * FROM threads
ORDER BY top_id DESC, path

Comments

[homepage-site]

Eggpanさん回答ありがとうございます、返信が遅れてしまい申し訳ありません。
返信できる深さについて悩んでいるのですが、深さに上限を設けた場合それ以上返信できなくなり、改めて質問に回答することになるので、深さの意味がなくなることが想定されます。
質問への回答、回答への返信などが入り乱れるので、ツリー型は実装したいです。

対策としてリンク又はボタンを表示しておいて、続きを見る際にアクションが必要という形にすることで解決するのではと考えました。
それが可能であれば無限の深さでも良いのではないかと思っているのですが、Eggpanさんならどうされますでしょうか？

[Eggpan]

回答への返信の返信まで表現したいのであれば無制限になっちゃうんじゃないかと思います。

あるいはteratailと同様に、回答の返信までは表示するとかですかね。
それ以上、4段階以上の中途半端な深さまで許可すると、ネストが深くなった段階で急に返信ボタンが出なくなるなどの状態が想定され、利用ユーザーがなぜ返信できないのかが分からなくなりそうです。

[homepage-site]

Eggpanさんアドバイスありがとうございます。
予想外の数でした…　ライブドアまとめブログのようにツリー数は無制限ではあるが、コードが複雑化するので深くしないという意味だと思っておりました。

SQLだけで返信機能を作成した場合に4段階以上はエラーが起こりうるという事でしょうか？

[Eggpan]

別にエラーは起きませんが、有限で中途半端な段階まで許可するとUI設計で困りませんか？
ユーザーが混乱しなければ良いのかなとは思います。

[homepage-site]

Eggpanさん回答ありがとうございます、あまり長くしすぎるとユーザー側も見にくいことは考えられますね。
ライブドアブログやYoutubeのようにコメントをツリー構造にして盛り上がるようにした方が既存のサイトと差別化できると考えていたんですが…

[homepage-site]

Eggpanさんに1つお聞きしたいのですが、CAST(id AS CHAR(255)) AS path は id を何故 CHAR型にしたのでしょうか？
VARCHAR型にするという選択肢もある中で理由をお聞きしたいです。