Q&A
> スレッドだけのカラムはたくさん（50個）ありますし
具体的に、どのようなカラムがあるのでしょうか。
###知りたいこと
掲示板のテーブル設計ですが、１と２はどちらがいいのでしょうか。
１．UNIONで生じるnullを許す
２．あらかじめカラムにnullを許す
###１．UNIONで生じるnullを許す
下記のように「threads」と「comments」というテーブルに分けるならば、それらのカラムにnullは生じません。
↓「threads」
↓「comments」
ここでユーザーが
・スレッド1をフォロー
・ユーザー80をフォロー
としていたとき、
彼のタイムラインに
・スレッド1へ投稿されたもの
・ユーザー80が投稿したもの
を流すことを考えます。
その情報を取得すると以下のように「threads」と「comments」をUNIONして、nullや0などで埋めないといけないカラムが出てきてしまいます。
↓「UNIONしたもの」
「thread_genre」は「threads」にしかないカラムだし、逆に「parent_comment_id」や「parent_thread_id」は「comments」にしかないカラムだからです。
###２．あらかじめカラムにnullを許す
他方、「threads」と「comments」というテーブルに分けず、下記のように「posts」に統合しておきますと、あらかじめnullを許しますが、UNIONするコストがかかりません。
タイムラインに流す情報の取得はSELECTだけで済みます。
↓「posts」
###改めて
ネットで検索する掲示板のテーブル設計といえば「threads」と「comments」をわけるものばかりです。
しかし、タイムラインのように「threads」と「comments」を統合して走査するケースがある場合に鑑みますと、２がいいのではと感じます。
タイムラインの情報としていずれにせよnullが介在せざるをえないのならば、２はUNIONのコストが不要なためです。
テーブル設計は初めての初学者で、他にいい方法なども存じません。
２にすべきか、１にすべきか、他にもっと適切な設計があれば知りたいです。
尚、実際には「thread_genre」以外にもスレッドだけのカラムはたくさん（50個）ありますし、逆にコメントにしかないカラムもこの例よりたくさんあります。（なのでWordPressのようにEVAを採用するとレコードが増えすぎて心配ですし、取得のSQLの煩雑さも懸念されますのでEVAは避けたいです。）
アドバイス宜しくお願い致します。
テーブルを作ってからどうにかしようとしてるから進まないわけで。
あと、質問についたアドバイスを一切受け入れるつもりないなら質問しないでもらいたいな。
そのスタンス続けると誰もアドバイスしなくなりますよ。
maisumakunさん、thread_time1、thread_time2のようなスレッドに関する微細な情報です。
画像とあわせてSQLの例示があると解説のしようもあるのですが
回答3件
0
そもそも論として、UNIONにはインデックスがかかりませんので、ある程度以上のデータ量を引くような場面では、速度が出ないため実用的になりません。
ということで、Postsにまとめるというのが適切となります。スレッドだけ、レスだけの項目については、別テーブルに切り出しておけばいいでしょう。
投稿2020/02/12 22:14
総合スコア145184
いつもありがとうございます。
「別テーブルに切り出す」と仰いますと？あまり専門的な表現ですと追いつけないのですが、例えば「threads_sub」と「comments_sub」というテーブルを作り、必要に応じてJOINする（というかスレッドもコメントもそのsub情報は必ず必要なので常にJOINする）というイメージでしょうか？
だとすると、JOINが必要になることと引き換えに、nullもUNIONもなくなり、１と２のいいとこどりに思えますね。
一つ疑問がございます。
subを使うというアドバイスですが、そのJOINのコストを、２でnullを許すことによるデメリットよりも小さく見積もっていらっしゃるということになるかと思います。ではそのデメリットとはどのようなものでしょうか？
0
ベストアンサー
ざっと見た感じ検索項目が違うなら別々に検索してあとで
合算すればいいような気がします。
煩雑になるほどむしろ項目名、値の組み合わせでデータを持つほうが
効率的かも
投稿2020/02/13 00:33
総合スコア114839
今回もご回答ありがとうございます。
>別々に検索してあとで合算すればいい
1回のSQLでnullを含むも結果を取得せず、threadsとcommentsにそれぞれSQLを流しnullはなくして、その結果をPHPで合算しソートするということですか？1回の方が速度面でのメリットが大きいように思えるのですが、速度を犠牲にしてまでnullを避けるのはどうしてなのでしょうか？
>煩雑になるほどむしろ項目名、値の組み合わせでデータを持つほうが
効率的かも
すみません、こちらはよくわかりませんでした。項目名、値の組み合わせでデータを持つ、というのは、どのような意味になりますでしょうか？
> 1回の方が速度面でのメリットが大きいように思えるのですが、速度を犠牲にしてまでnullを避けるのはどうしてなのでしょうか？
逆です。1回でやることにこだわるとスピードを犠牲にします。
別テーブルから別のSQLを実行するならそれぞれにSQLを
発行するほうが圧倒的に効率的です
> 項目名、値の組み合わせでデータを持つ、というのは、どのような意味
それを聞くなら、ご自身のテーブル設計をきちんと表示すべきです
create table+insert文で例示いただければ
こうしたらもっと効率的という修正方針も示せるかもしれません。
なるほど、スピードの件まったく思いつきませんでした。ありがとうございます。
create table+insert文の例示ですが、他の質問との兼ね合いもあり、ひとまずあいまいな状態で画像だけで質問してしまっておりました。まだ具体的な細部が未定です。にも拘わらずできる限りのご回答を頂いたことに改めて感謝申し上げます。
0
彼のタイムラインに
・スレッド1へ投稿されたもの
・ユーザー80が投稿したもの
を流すことを考えます。その情報を取得すると以下のように「threads」と「comments」をUNIONして
threads → comments という関係だからunionじゃなくてjoinでしょう。
そもそも、同じタイミングで発生するもので無い限りNullは発生します。
正規化されている状態でも、outer join すればNUllは絶対発生するものですから、これらのNull考慮はテーブル設計の段階で決まっている事です。
投稿2020/02/13 00:58
総合スコア25195
こんにちは。いつもお世話になっております。
joinというのは横に連結する処理ですよね？しかしそれではタイムラインとしての表示（日付順に縦に並んだ表示）ができないのではないかと感じます。
スレッドt1,t2,t3が縦に並び、そのスレッドへのコメントが横に連結されると下記のようなテーブルが取得されると思うのですが、
1行目：t1のカラム, t1-c1のカラム, t1-c2のカラム, t1-c3のカラム
2行目：t2のカラム, t1-c1のカラム, t1-c2のカラム
3行目：t3のカラム, t1-c1のカラム, t1-c2のカラム
ここからどうやってタイムラインとしての表示をソートすればいいのか、お恥ずかしながらイメージが及びません。（尚取得されたテーブルはPHPでjson_encodeしてJSで受け取る予定です。）
また上記はt1へのコメントを3件としていますが、もし1000件あったとき横に大変な長さでカラムが連結されてしまいますが、そこは不自然ではないのでしょうか。
> 1行目：t1のカラム, c1のカラム, c2のカラム, c3のカラム
JOINの考え方がおかしいです。
「t1-c1」「t1-c2」「t1-c3」のような感じの多数の行が取れます。
なるほど。t1へのコメントは横にずっと連結されるのかと思っていました。改めてJOINをいくつか試して勉強しておきます。
threadsに対して複数のcommentsがある場合、それをjoinすると縦方向（複数行）展開されます。
これを、threads1行に纏めてcommentsを横方向に展開するような事は、クロス集計と呼びます。
MySQLだと結構手間(GROUP_CONCAT()が利用できるとは思います）なので、取得した側で編集する事も視野に入れられた方が良いかと思います。
なるほど、勝手にクロス集計をイメージしておりました。ケースバイケースで手間を考慮し手段を選定できるように早くなりたいです。
あなたの回答
tips
プレビュー
