WordPressの質問（q10271965）の続

質問

アップロードファイルを質問UUID_ファイル番号.拡張子で保存するようにコードを変更してみたのですが、間違っているところなどありますでしょうか？

functions.phpの141行目に質問UUIDを読み込んで取得するコードを追加いたしました
bbs_que_list.phpの10行目に質問IDを追加するコードをコメントアウトいたしました
bbs_que_list.phpの19行目に質問UUIDを追加いたしました

※最新コード
https://wandbox.org/permlink/6MkU8D39XMbr2822

質問掲示板から動画のみで投稿したところ動画横スクロールと同じものが無限スクロールでも表示されております。

以前までは投稿に画像がない場合ダミー画像を表示していたので、functions.php にコードを追加した際に問題が発生しているようです。
原因となるコードは分かりますでしょうか？

※旧コード
https://wandbox.org/permlink/M4yGxrYf0PWv5L9g

※質問一覧表示画面
https://www.irasuto.cfbx.jp/%e9%9b%91%e8%ab%87%e6%8e%b2%e7%a4%ba%e6%9d%bf%e3%80%80%e8%b3%aa%e5%95%8f%e4%b8%80%e8%a6%a7%e8%a1%a8%e7%a4%ba%e7%94%bb%e9%9d%a2/

回答No.26

dell_OK · ベストアンサー

・回答画面の返信機能についてカラムを幾つ追加すべきでしょうか？参考サイトから返信 ID は必要だと考えました。

そうですね。
返信ＩＤのひとつだけでいいと思います。

・質問画面の HTMLクラス名を question で維持したままカラム名のみ text に変更することは可能でしょうか？

可能です。
修正もれがいくつかあるようですので、クラス名以外は text にしてください。

・名前のカラムについて namae としていたのですが、1つだけローマ字なので name の方が良いのではないかとアドバイス頂きこちらも変更すべきではないかと思いました。

そうですね。
その方がいいと思います。

テーブル構成を変更して動作確認してみてください。

お礼

こちらが最新の質問になります。
質問の期限が切れてしまっておりました、下記URLからアドバイスよろしくお願い致します。

https://okwave.jp/qa/q10288298.html

補足

Q.修正もれがいくつかあるようですので、クラス名以外は text にしてください。

テーブル構成を変更して動作確認してみてください。

A.回答ありがとうございます、下記コードはすべて text にしても良いのでしょうか？

bbs_quest_input.php の101行目 name="question"

bbs_quest_input.php の214行目 var question_value = "";

bbs_quest_input.php の335行目 if (!['name', 'title', 'question'].includes(e.target.id)) return;

bbs_quest_input.php の364行目 question_value = "";

bbs_quest_input.php の390行目 question_value = json.question;

※最新コード
https://wandbox.org/permlink/PjhrH75IR9jUMnpL

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

以前 dell_ok さんに教えて頂いた質問と回答と返信を識別する2択の方法についてどちらが良いかお聞きしたところ➁一択とのことでした。

頂いたアドバイスから考えると返信ＩＤ は必要ない可能性もありそうですが、そうした場合、返信できる深さの上限を浅くまでしか設定できないのではないかと思っております。

dell_ok さんはどう思われますでしょうか？

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

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

理由は下記になります。

回答にさらに回答が付くことがある（返信）ということなので、メッセージはメッセージとして前後関係や親子関係のようにとらえて属性付けして管理していくのが良いです。
前(親)が無いものが原始(root)のメッセージというような考えかたになるでしょう。

上記とは別のアドバイスも頂きました。テーブル構成➁が良く、親IDを利用した自己結合が必要になってくるはずです。

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

テーブルの例（SQL）

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つ目の親メッセージの返信への返信です');

_____________________________________________________

テーブルの例（SQL、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

回答No.25

dell_OK

なるほど、承認制のうえで投稿間隔制御することでかなりよくなりそうですね。
テーブル構成としては表示フラグの追加でよさそうですね。
承認の管理画面を新たに作る必要がありますが、それは後回しにして、それまでは表示フラグをtrueで登録しておいて、回答画面の開発やテストをしていきましょう。
承認は回答だけではなく質問にも必要になると思いますので、管理画面のことを考えると、テーブルは両用の方がいいかも知れませんね。

補足

回答ありがとうございます、両用テーブルで考えてみました。回答画面の返信機能についてカラムを幾つ追加すべきでしょうか？参考サイトから返信 ID は必要だと考えました。

カラムの question は両用にする場合、回答機能と併用する場合名前を変更したほうがよいとアドバイス頂き text に変更したいです。
質問画面の HTMLクラス名を question で維持したままカラム名のみ text に変更することは可能でしょうか？

名前のカラムについて namae としていたのですが、1つだけローマ字なので name の方が良いのではないかとアドバイス頂きこちらも変更すべきではないかと思いました。

※現在の質問、質問一覧表示画面コード
https://wandbox.org/permlink/VZKaC9SNcA4xQ2Iz

※上記カラム名修正後のコード
https://wandbox.org/permlink/EnwUkw878HiXGRSB

※参考サイト
https://qiita.com/ryouya3948/items/6928c89607cf4eaa72a0

※両用テーブル
ID (質問番号)・・・・識別用のカラム
TS (投稿日時)・・・・公開期間終了後に質問を cron で削除するため？、回答の日時を把握する（〇日前）
question (内容)・・・・質問、回答の投稿文
title (タイトル)・・・・質問タイトル
namae (名前)・・・・質問、回答者名
stamp (リアクションスタンプ)・・・・質問スタンプ
unique_id (質問UUID)・・・・アップロードされたファイル名の改名に使用
ip (IPアドレス)・・・・セキュリティ保護のために保存
attach1 (アップロードされたファイル)・・・・1、2、3で分けているのは1つ目の画像を一覧表示＆1つ目の動画を横スクロールで表示するため
attach2 (IPアドレス)・・・・略
attach3 (IPアドレス)・・・・略
usericon (アイコン画像)・・・・質問、回答のアイコン画像
＋
comment_id (回答に対する返信のID)・・・・返信 ID

回答No.24

dell_OK

ログイン制についてですが、これまでログイン制ではなかったのでやらなくてよかったことがいくつかあったと思います。
近いところではブルートフォース攻撃、以前ではＣＳＲＦも、不要という判断になりました。
他にもあったかも知れません。
これらをさかのぼって対応するのは大変ですし、正直、私には手に負えないことになりそうなので遠慮したいところです。
ひとまずはサイトとしてのひととおりの機能を実装することを優先していただき、そこまではお手伝いできると思いますが、セキュリティに関しては有識者の方々を頼りにしてあとから着手されてはいかがでしょうか。
あとからの手間は増えますが、機能が完成しているところへの追加になると思いますので、機能とセキュリティを同時に考えながら作るよりも、それぞれの開発に集中できる方がいいような気もします。
セキュリティとは言えないまでも、簡易的な対策として認証制があればいいような気はしています。
ログイン制にしたとしても、あやしいことを投稿する人がいないわけではないのは、多くのログイン制のサイトが抱える問題のひとつだと思いますし。

お礼

説明が不足しておりました申し訳ありません。
ログインではなく承認制にすることのデメリットとして、荒らしを対策にしては管理者の手間がかかすぎることだと教えて頂いたので、そちらの欠点を補う方法として N（秒分）間の投稿規制やCAPTCHAでの認証システムは有効ではないかと考えました。

ファイル名の「{質問UUID}_{ファイル番号}.{拡張子}」について勘違いをしていたのですが、質問UUID_1、質問UUID_2、質問UUID_3の「質問UUID」の部分は同一である場合に「確定的にファイル名が判明する」という指摘であったようです。

補足

A.アドバイスありがとうございます、負担をかけてしまい本当に申し訳ありません…
dell_ok さんの言う通りログイン制にするにはかなりの労力がかかり更なるセキュリティのリスクを抱えることになると思っております。
また既存のログイン制イラスト投稿サイトがありヤフー知恵袋と競合することになるため負けてしまうと思われます。

そこで考えていることがあるのですが N（秒分）間の投稿規制と投稿を承認後に表示させるという方法になります。
CAPTCHAでスパム対策もスパム対策として実装するのも良さそうです。

以前アドバイス頂いた際に投稿をRDBで管理しているのであれば投稿時には表示フラグをfalseにしておいて、管理者の管理画面で表示フラグをtrueにすれば投稿を承認制にできるということを教えて頂きました。
カラムとコードが増えてしまうのが予測されますが、回答専用テーブルを用意して質問専用テーブルと結合（ＪＯＩＮまたはＵＮＩＯＮ）リレーショナルデータベースにすることで SQL から投稿の表示を制限することが出来ると思われます。

※JavaScript製のCAPTCHAで簡単スパム対策
https://oilabo.vercel.app/blog/2021/jcap/

回答No.23

dell_OK

・両用テーブルで良いという意見が複数あり、どちらにすべきか迷っております。

そうですね。
これには正解はないような気がします。
意見が分かれるのは、
それぞれの人が何を重視したかによる好みでしょうから、
絶対これしかないと言うものではないように思います。
それに、質問者さまのしたいことを伝えきれていなかったり、
理解されていなかったりするのもあるかも知れません。

私が個人的に思うことを述べておきます。

質問と回答の関係を図にしてみるとこんな感じです。

質問１
　質問１の回答１
　質問１の回答２
　質問１の回答・・・
質問２
　質問２の回答１
　質問２の回答・・・
質問・・・
　・・・

まずは個別テーブルにした場合のテーブル構成を考えてみます。
質問テーブル
　質問ＩＤ
　ほか
回答テーブル
　質問ＩＤ
　回答ＩＤ
　ほか

プログラムの処理としては、
質問テーブルを質問ＩＤで参照し、
そのデータで質問の出力を編集。
回答テーブルを質問ＩＤで参照し、
そのデータで回答の出力を編集。
回答は複数件の場合があるので編集は０件以上のループ処理。
この方法では質問と回答で別々にＳＱＬを実行することになります。

次に両用テーブルにした場合のテーブル構成を考えてみます。
質問回答テーブル
　質問ＩＤ
　回答ＩＤ
　ほか
質問か回答かの判断は回答ＩＤでします。
質問：回答ＩＤがＮＵＬＬである
回答：回答ＩＤがＮＵＬＬでない

プログラムの処理としては、
質問回答テーブルを質問ＩＤで参照し、
そのデータが質問であれば質問の出力を編集、
そのデータが回答であれば回答の出力を編集。
質問と回答を合わせて１件以上のループ処理。
この方法では質問と回答を同時に取得できるのでＳＱＬの実行は１回になります。
あえて別々に実行することもできますが、する意味はないです。

こう見ると、両用テーブルの方がすっきりしているように見えます。

個別テーブルの場合でもＳＱＬの実行を１回にする方法はあります。
質問テーブルと回答テーブルを結合（ＪＯＩＮまたはＵＮＩＯＮ）する方法です。
結合による無駄や手間があるので、あまりメリットがないと言うか、
ＵＮＩＯＮにすれば両用のプログラム処理に似通ってくるのですっきりはしますが、
わざわざ個別テーブルにしたのは何のためだかわからなくなってきます。

少し、判断材料を考えてみましょう。

ひとつめ。
それぞれのテーブル構成が違う場合は個別テーブルの方が向いています。
テーブル構成が違うと言う事は共通処理があまりないでしょう。
しかし、上記の構成で「ほか」と書いたカラムは、質問も回答もほとんど同じものばかりです。
もしかしたら処理も共通な部分が多くあるかも知れません。

ふたつめ。
質問しか見ないことがよくあるのでしたら、
データベースにかかる負荷を軽減する意味では個別テーブルは有効です。
質問テーブルには質問しかないのですから、
データベースは読み書きに必要なデータ領域しかアクセスしません。
両用では回答を除いて参照する必要がありますし、
データベースは質問と回答のまざったデータ領域を読み書きすることになります。

補足

Q.こう見ると、両用テーブルの方がすっきりしているように見えます。

A.解説ありがとうございます、テーブルを分けるとカラムとコードが増えそうですね。

Q.個別テーブルの場合でもＳＱＬの実行を１回にする方法はあります。
質問テーブルと回答テーブルを結合（ＪＯＩＮまたはＵＮＩＯＮ）する方法です。
結合による無駄や手間があるので、あまりメリットがないと言うか、
ＵＮＩＯＮにすれば両用のプログラム処理に似通ってくるのですっきりはしますが、
わざわざ個別テーブルにしたのは何のためだかわからなくなってきます。

A.解説ありがとうございます、dell_ok さんがおっしゃられるように同じテーブルに投稿をまとめた場合、リプレイスやリファクタリングでテーブルを分けるのは簡単ですが、その逆は困難なようです。

Q.ひとつめ。
それぞれのテーブル構成が違う場合は個別テーブルの方が向いています。
テーブル構成が違うと言う事は共通処理があまりないでしょう。
しかし、上記の構成で「ほか」と書いたカラムは、質問も回答もほとんど同じものばかりです。
もしかしたら処理も共通な部分が多くあるかも知れません。

A.解説ありがとうございます、テーブル構成について dell_ok さんと同意見の方がおられました。
テーブルの構成がほぼ同じで共通処理が多い場合は両用テーブルが良さそうですね。

※頂いたアドバイス
質問と回答に保存する内容が極端に違うのであれば分けてもいいが、回答に対してレスができる枝分岐していくような仕組みを模索するなら一緒の方が管理が楽だと思います。

Q.ふたつめ。
質問しか見ないことがよくあるのでしたら、
データベースにかかる負荷を軽減する意味では個別テーブルは有効です。
質問テーブルには質問しかないのですから、
データベースは読み書きに必要なデータ領域しかアクセスしません。
両用では回答を除いて参照する必要がありますし、
データベースは質問と回答のまざったデータ領域を読み書きすることになります。

A.解説ありがとうございます、データベースの負荷についても新たにアドバイス頂いたのですが、10日で削除することを考慮すると両用でも問題ないとのことでした。
データ属性の拡張をしやすくなるメリットがあるようですが、データ蓄積型でなければカラムやコードをまとめられる両用の方が良いというまとめになりました。

※頂いたアドバイス
設計上10日ほどで古いものを削除する運用であることから、データが増えた場合の性能低下を考慮する必要性が薄いです。
運営時間に応じてデータが増えていくサイトを目指すのであればテーブルを分けます。
以下理由になります。

➀テーブルを分けなかった場合、一番アクセスの多いであろう質問一覧画面を表示するためにwhere句で item_type = 1 の絞り込みが必要になり、DBを効率的に扱えない
➁感覚上テーブルを正規化して作りにくくなったことはあまりない
➂分けることによって質問だけ、回答だけのデータ属性を拡張しやすくなる

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

上記とは別に何故会員登録制の掲示板が多いのかログイン画面は必要なのかコメントの認証制について教えて頂いたのですが、
管理者の負荷が大変なのでログイン制を導入することが多く、投稿までのプロセスを複雑化することでリスクを現象させるようです。
誰でも気軽に投稿できる掲示板を考えていたのですが、メールアドレスからの認証やログインシステムをなくす場合、最低限目視でチェックする承認制度をとるのが良いのかもしれないです…
不特定多数が書き込める現在の掲示板ではセキュリティの穴があると別の方からもご指摘頂いたので考え直しております…

登録するとメールが返ってきてその内容に従ってアクセス、入力欄を埋める、荒らしをする方は「面倒な」手続きを嫌う傾向がある為に CAPTCHA などの導入も進んでいる。
人が個別に入力しているものは基本的に入力時には防げないので、そこに至るまでを複雑化して対処するしかない。
ログイン不要の誰でも書き込める掲示板は機械的なモノでも楽々書き込めるので、それよりは安全である。
入力欄が複数あると全部に入力しようとする場合が多いので、空欄である事が必要と日本語で書いておくなど海外への荒らし対策がある。

回答No.22

dell_OK

・専用テーブルか両用テーブルかということについてお聞きしたところ

それでは専用テーブルに決まりでしょうかね。

・ファイル名は以前 UUID に変更したと思うのですが、推測しやすいものになっている

そうですね。
ファイル名はＵＵＩＤにしたので何も推測されない、
もしくは推測されても何も問題ないと思うので、
アドバイザーの意図がわかりません。
もともとファイル名に質問ＩＤ（１からの連番）を含んでいたため、
質問ＩＤを推測されないために施したのがファイル名のＵＵＩＤです。
このＵＵＩＤも質問ＩＤを推測されないために、質問画面へのＵＲＬに使うためのものです。
結局のところＵＵＩＤを使っていることは閲覧者にはわかるので、
これ以上どこをどうしたとしてもあまり変わりのないことのように思います。
アドバイザーの言葉を読む限りでは、なんとなくですが、
こちらとしてはファイル名をＵＵＩＤにしている決定事項が、
いまだ未確定要素になっていると思われている感じがします。

・ログイン無しの自由に書き込み可能な掲示板を考えていたのですが、かなり危険だと複数回指摘頂いたので承認制に変更すべきではないか

それはそうですね。
ですが、ログインありにすると言う事は、ユーザー登録が必要となり、誰もが参加しやすい環境ではなくなり、利用者の増加が望めなくなるおそれがある、と言う話しをずっと前にしたと思います。
以前にやった、記事へのコメント機能、の時だったかと思います。
現在でも記事へのコメントは誰でも可能です。
その対策として、「reCAPTCHA」を使って「ロボットではない」判定をしたように思います。
先のＵＵＩＤに関してもですが、これに対して推測したもので猛烈にアクセスしてくるのは人ではなくロボットです。
質問掲示板にも「reCAPTCHA」を導入することで、そのあたりの危険を軽減できるのではないかと思います。
ただ、非同期型なので「reCAPTCHA」が簡単に使えるのかどうかわかりません。

補足

・専用テーブルか両用テーブルかということについてお聞きしたところ

それでは専用テーブルに決まりでしょうかね。

A.回答ありがとうございます。回答を待っていたところ両用テーブルで良いという意見が複数あり、どちらにすべきか迷っております。

※両用テーブルで良いという意見について
➀関係を示す別テーブル(中間テーブル)は、この場合は不要ではないでしょうか？
基本的にN対Nで、例えば質問テーブルに回答IDがない場合があり、回答テーブルに質問IDがない場合がある。という設計であれば有効かと思いますが……
必要になるかもしれないからとりあえず作る、という設計には否定的な立場での意見です。

➁ひとつのテーブルでいいと思いますコードをまとめられますから
関係的に1:1でないこととテーブルを分けることになんの関連性があるんだろうか？
例えばTwitterとかは、投稿1つに対して複数の返信がありえて、再帰的にこれが起きるけど、
返信テーブルが無限にあるという考えなのだろうか？(システムに制限があるのか、無限に返信出来るかどうかは知らんが)

Q.こちらとしてはファイル名をＵＵＩＤにしている決定事項が、
いまだ未確定要素になっていると思われている感じがします。

A.回答ありがとうございます。もう一度 ＵＵＩＤ に関してお聞きしてみます。

Q.ログインありにすると言う事は、ユーザー登録が必要となり、誰もが参加しやすい環境ではなくなり、利用者の増加が望めなくなるおそれがある、と言う話しをずっと前にしたと思います。
以前にやった、記事へのコメント機能、の時だったかと思います。
現在でも記事へのコメントは誰でも可能です。
その対策として、「reCAPTCHA」を使って「ロボットではない」判定をしたように思います。
先のＵＵＩＤに関してもですが、これに対して推測したもので猛烈にアクセスしてくるのは人ではなくロボットです。
質問掲示板にも「reCAPTCHA」を導入することで、そのあたりの危険を軽減できるのではないかと思います。
ただ、非同期型なので「reCAPTCHA」が簡単に使えるのかどうかわかりません。

A.回答ありがとうございます。自分もロボットに対しての対策だと思っていたのですがそれ以外にも詐欺や迷惑な広告、フィッシングがテンコ盛りの投稿ばかりになったり、不適切な画像（動画、PDF）の貼り込みが大量に張られたりすることが想定されるという事でした…
ユーザー登録だと敷居が高い気がするので一度投稿を非公開にしてワンクッション置く方が良いかもしれないです…

回答No.21

dell_OK

・foreach ($files as $file) {} のループが2回繰り返されている

私のミスです。

補足

専用テーブルか両用テーブルかということについてお聞きしたところ、関係的に１：１とは限らないため別テーブルにすべきだという回答を頂きました。関係を示す情報も別テーブルとする方が拡張性は高いようです。

質問テーブルにも指摘を頂きました。ファイル名は以前 UUID に変更したと思うのですが、推測しやすいものになっていると dell_ok さんは思われますでしょうか？

ログイン無しの自由に書き込み可能な掲示板を考えていたのですが、かなり危険だと複数回指摘頂いたので承認制に変更すべきではないかと感じました…

※頂いたアドバイス
➀attach1(UUID-1)、attach2(UUID-2)、attach3(UUID-3)というファイル名ではなく、ファイル名をそれぞれ別のUUIDにした方が「○○を推測される恐れ」は回避できます。
ファイル名に関してはアップロードされたファイル名をそのまま使うのは危険なので、何らかの処理が必要ですが、UUIDにしてしまうのは手っ取り早い方法だと思います。

※質問テーブル例
id INT UNSIGNED NOT NULL AUTO_INCREMENT
commentId INT UNSIGNED NOT NULL
sortOrder TINYINT UNSIGNED NOT NULL DEFAULT 0
displayName VARCHAR(40) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL
filename VARCHAR(40) NOT NULL
createdAt DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
今時のデータベースはリレーションが出来て当たり前なので、１行の中に全部を持っていなければいけない理由は無いと思います。
＿＿filenameカラムに保存時の実ファイル名（UUID等）をセット
＿＿UUIDがあるのにidをPKにしているのは、ブラウザ上でのファイル名は id を基にしたその場限りのモノにして再利用等を防げないかなと思ったり...

➁ログイン無しのQ&A掲示板は「ログイン必要」にするだけで（スパム的な）迷惑な書き込みや危険なリンク先や不適切な画像の貼り込みを「かなり」避けられます。
誰でも何回でも投稿できる仕組みは危険が一杯です、最低限投稿された質問を承認制にした方が良いと思います。

回答No.20

dell_OK

・返信機能にもう１ついいね数を追加してみたいと考えているのですが、Ajax と合体させるのは難しいのではないか

どのAjaxと合体するのかわかりませんが、すでにあるコードと合体ではなく、
それ専用のJavaScriptとPHPを備えればそんなに難しいことではないと思います。

・あまり必要ない機能だと思われますでしょうか？

それは、そのサイト利用者がどれくらいいるかにもよると思います。
多くの人が、その質問と回答を閲覧するのであれば、
その質問が有益であるとか回答が信頼に値するものだと判断するのにはいい機能だとは思います。
ただし、それには良識のある人たちの「いいね」であることが前提です。
人が多ければ多いほどに「いいね」が悪用されるような事件もあるようなので。
質問があまりにも一般的なものではなくて、その人固有の内容だったりすると、
スルーされがちになるので、いいねの出番がなくなります。
そのような質問が多いのであればなくてもさしつかえない機能だと思います。

補足

A.アドバイスありがとうございます。属人的になるのは避けたいので実装しないほうがよいのではないかとも考えたのですが、掲示板全体が活性化するのにはとても有効だと思いました。
いいね機能を実装する方向で考えたいです。

回答No.19

dell_OK

・新たにカラムに追加すべきでしょうか？

それはテーブルをどのようにもたせるかにもよります。

既存のsortableを質問専用にするのであれば、
回答専用のテーブルそのものを追加する必要があります。
なので必要な項目はすべてで構成してください。
ただ、「コメントをしたユーザーID」は不要です。
質問者さまのサイトはユーザー管理をしていないためです。

既存のsortableを質問回答両用にするのであれば、
日時はすでにあるのでいいとして、
そのデータが質問か回答かを識別できるカラムを追加することになると思います。
その前に、その回答がどの質問に対しての回答なのか、
回答No.18で必要と回答したその紐づけのための質問ＩＤが必要です。
ここでは「親ＩＤ」と呼ぶことにします。
それでと。
質問か回答かを識別するには２つの方法があります。
ひとつは、識別用のカラムを持たせる方法で、
例えば、質問を「1」、回答を「2」のように意味付けて識別します。
もうひとつは、先ほどの親ＩＤがNULL（紐づけられていない）のものを質問とし、
親ＩＤが設定されているものを回答とするものです。

専用テーブルか両用テーブルか、
両用テーブルの識別カラムの有無、などは、
多くのＱ＆Ａサイトがどのようにしているのかはわかりません。
もしかしたらそれぞれにメリットとデメリットがあるのでしょうが、
比べてもさしてかわらない、とるにたらないようなことかも知れません。

回答No.18

dell_OK

・入力画面に投稿されたものと回答機能の紐付けは必要でしょうか？

必要です。

参考サイトの掲示板は、投稿されたものが列挙されるだけのものです。
質問機能と回答機能を備えているものではありません。
「回答編」とあるので回答機能と思われたのかも知れませんが、
その回答機能ではありません。
このサイトの主が先に書かれた質問編のような記事があり、
その回答を示しているもののようです。

補足

A.アドバイスありがとうございます、紐付けについて調べてみます。

回答No.17

dell_OK

・ファイルアップロード1,2,3をすべて表示したい場合は下記のようなコードになるのでしょうか？
echo '<div>' .$row->attach1、$row->attach2、$row->attach3.'</div>';

ファイル名を表示するだけならそのようなコードになります。
画像や動画またはＰＤＦを表示するとなると、最大３ファイルの処理をするループが必要になってきます。
ループするには配列にする必要があるので、例えば、こんな感じになります。
－－－－
$files = [$row->attach1, $row->attach2, $row->attach3];
foreach ($files as $file) {
foreach ($files as $file) {
$info = pathinfo($file);
$attach_url = $upload_dir['baseurl'].'/attach/'.$info['basename'];
$ext = $info['extension'];
switch ($ext) {
case 'jpeg':
case 'png':
$view = '<img style="height: 50px;" src="'.$attach_url.'">';
break;
case 'mp4':
$view = '<video style="height: 50px;" src="'.$attach_url.'">';
break;
case 'pdf':
$view = '<iframe style="height: 50px;" src="'.$attach_url.'"></iframe>';
break;
default:
$view = '';
break;
}
}
}
－－－－

補足

A.回答ありがとうございます。attach はファイル名だけなのを忘れておりました申し訳ありません。
拡張子と URL はここで設定するんですね。
foreach ($files as $file) {} のループが2回繰り返されている理由が分からないのですが、下記のコードを3回ループするからでしょうか？

foreach ($files as $file) {
$info = pathinfo($file);
$attach_url = $upload_dir['baseurl'].'/attach/'.$info['basename'];
$ext = $info['extension'];
switch ($ext) {
・
・
・
　　　　 （略）
}
}

回答No.16

dell_OK

・共通部分をまとめることは可能でしょうか？

まったく同じであれば可能だと思います。
まとめるのは後にして、まったく同じコードになるかどうか完成してからの判断でいいと思います。

・attach1,attach2,attach3 すべて表示したい場合テーブルを一括で選択する方法はありますでしょうか？

テーブルではなくてカラムですね。
ＳＱＬ文が「SELECT * FROM ～」になっていればすべて取得できます。

・echo '<div>' .$row->attach.'</div>'; ではテーブル名が存在しない為どうすべきか悩んでおります。

カラム名は$row->attach1、$row->attach2、$row->attach3になります。

補足

Q.まとめるのは後にして、まったく同じコードになるかどうか完成してからの判断でいいと思います。

A.アドバイスありがとうございます。
深く考えてみたところ同じ作りではなさそうです。

Q.テーブルではなくてカラムですね。
ＳＱＬ文が「SELECT * FROM ～」になっていればすべて取得できます。

・echo '<div>' .$row->attach.'</div>'; ではテーブル名が存在しない為どうすべきか悩んでおります。

カラム名は$row->attach1、$row->attach2、$row->attach3になります。

A.回答ありがとうございます。
テーブルとカラムが逆でした申し訳ありません、ファイルアップロード1,2,3をすべて表示したい場合は下記のようなコードになるのでしょうか？
echo '<div>' .$row->attach1、$row->attach2、$row->attach3.'</div>';

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

コードを書く前に回答機能の設計についてアドバイスを頂きたいのですが、入力画面に投稿されたものと回答機能の紐付けは必要でしょうか？
参考サイトの Ajax を見ると回答を送信した後に真下に表示する形になっているため質問と回答は切り離されているように見えました。

※参考サイト（PHP掲示板回答編）
https://took.jp/post-1750/

回答一覧の返信機能についてもアドバイス頂きたいのですが、参考サイトのようにコメントに対するコメントのID、コメントをしたユーザーID、コメントをした投稿ID、コメントをした時刻を新たにカラムに追加すべきでしょうか？
回答された日を○日前と表示したいのでコメントをした時刻は必要だと思っております。

※参考サイト（コメント機能実装）
https://qiita.com/ryouya3948/items/6928c89607cf4eaa72a0

返信機能にもう１ついいね数を追加してみたいと考えているのですが、Ajax と合体させるのは難しいのではないかと思い諦めるべきか悩んでおります…
dell_ok さんはあまり必要ない機能だと思われますでしょうか？

※参考サイト（PHPとjqueryでいいね機能実装）
https://zenn.dev/torihazi/articles/2fefc4b673aea7

※回答画面配置

※入力画面に投稿されたもの
タイトル　　　スタンプ
アップロードファイル×3　メッセージ
アイコン画像　名前
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

※回答機能
アイコン画像　名前
　　　　　　　回答
ファイルアップロード×3
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

※回答一覧
ア　　　　　　名前　○日前
ッ　　　　　　回答
プ　　　　　　アイコン画像　返信ボタン
ロ　　　　　　○件の返信
｜
ド
フ
ァ
イ
ル