質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.82%

データベース設計におけるnullの扱い

解決済

回答 3

投稿

  • 評価
  • クリップ 0
  • VIEW 782

ikatako

score 149

知りたいこと

掲示板のテーブル設計ですが、1と2はどちらがいいのでしょうか。

1.UNIONで生じるnullを許す
2.あらかじめカラムにnullを許す

1.UNIONで生じるnullを許す

下記のように「threads」と「comments」というテーブルに分けるならば、それらのカラムにnullは生じません。

↓「threads」
イメージ説明

↓「comments」
イメージ説明

ここでユーザーが
・スレッド1をフォロー
・ユーザー80をフォロー
としていたとき、

彼のタイムラインに
・スレッド1へ投稿されたもの
・ユーザー80が投稿したもの
を流すことを考えます。

その情報を取得すると以下のように「threads」と「comments」をUNIONして、null0などで埋めないといけないカラムが出てきてしまいます。

↓「UNIONしたもの」
イメージ説明

「thread_genre」は「threads」にしかないカラムだし、逆に「parent_comment_id」や「parent_thread_id」は「comments」にしかないカラムだからです。

2.あらかじめカラムにnullを許す

他方、「threads」と「comments」というテーブルに分けず、下記のように「posts」に統合しておきますと、あらかじめnullを許しますが、UNIONするコストがかかりません。
タイムラインに流す情報の取得はSELECTだけで済みます。

↓「posts」
イメージ説明

改めて

ネットで検索する掲示板のテーブル設計といえば「threads」と「comments」をわけるものばかりです。

しかし、タイムラインのように「threads」と「comments」を統合して走査するケースがある場合に鑑みますと、2がいいのではと感じます。

タイムラインの情報としていずれにせよnullが介在せざるをえないのならば、2はUNIONのコストが不要なためです。

テーブル設計は初めての初学者で、他にいい方法なども存じません。
2にすべきか、1にすべきか、他にもっと適切な設計があれば知りたいです。

尚、実際には「thread_genre」以外にもスレッドだけのカラムはたくさん(50個)ありますし、逆にコメントにしかないカラムもこの例よりたくさんあります。(なのでWordPressのようにEVAを採用するとレコードが増えすぎて心配ですし、取得のSQLの煩雑さも懸念されますのでEVAは避けたいです。)

アドバイス宜しくお願い致します。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • maisumakun

    2020/02/13 07:10

    > スレッドだけのカラムはたくさん(50個)ありますし

    具体的に、どのようなカラムがあるのでしょうか。

    キャンセル

  • m.ts10806

    2020/02/13 08:56

    テーブルを作ってからどうにかしようとしてるから進まないわけで。
    あと、質問についたアドバイスを一切受け入れるつもりないなら質問しないでもらいたいな。
    そのスタンス続けると誰もアドバイスしなくなりますよ。

    キャンセル

  • ikatako

    2020/02/13 09:29

    maisumakunさん、thread_time1、thread_time2のようなスレッドに関する微細な情報です。

    キャンセル

  • yambejp

    2020/02/13 09:30

    画像とあわせてSQLの例示があると解説のしようもあるのですが

    キャンセル

回答 3

+3

そもそも論として、UNIONにはインデックスがかかりませんので、ある程度以上のデータ量を引くような場面では、速度が出ないため実用的になりません。

ということで、Postsにまとめるというのが適切となります。スレッドだけ、レスだけの項目については、別テーブルに切り出しておけばいいでしょう。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/02/13 09:27 編集

    いつもありがとうございます。

    「別テーブルに切り出す」と仰いますと?あまり専門的な表現ですと追いつけないのですが、例えば「threads_sub」と「comments_sub」というテーブルを作り、必要に応じてJOINする(というかスレッドもコメントもそのsub情報は必ず必要なので常にJOINする)というイメージでしょうか?

    だとすると、JOINが必要になることと引き換えに、nullもUNIONもなくなり、1と2のいいとこどりに思えますね。

    キャンセル

  • 2020/02/13 09:39

    一つ疑問がございます。
    subを使うというアドバイスですが、そのJOINのコストを、2でnullを許すことによるデメリットよりも小さく見積もっていらっしゃるということになるかと思います。ではそのデメリットとはどのようなものでしょうか?

    キャンセル

checkベストアンサー

+2

ざっと見た感じ検索項目が違うなら別々に検索してあとで
合算すればいいような気がします。
煩雑になるほどむしろ項目名、値の組み合わせでデータを持つほうが
効率的かも

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/02/13 09:48

    今回もご回答ありがとうございます。

    >別々に検索してあとで合算すればいい
    1回のSQLでnullを含むも結果を取得せず、threadsとcommentsにそれぞれSQLを流しnullはなくして、その結果をPHPで合算しソートするということですか?1回の方が速度面でのメリットが大きいように思えるのですが、速度を犠牲にしてまでnullを避けるのはどうしてなのでしょうか?

    >煩雑になるほどむしろ項目名、値の組み合わせでデータを持つほうが
    効率的かも
    すみません、こちらはよくわかりませんでした。項目名、値の組み合わせでデータを持つ、というのは、どのような意味になりますでしょうか?

    キャンセル

  • 2020/02/13 19:49 編集

    > 1回の方が速度面でのメリットが大きいように思えるのですが、速度を犠牲にしてまでnullを避けるのはどうしてなのでしょうか?

    逆です。1回でやることにこだわるとスピードを犠牲にします。
    別テーブルから別のSQLを実行するならそれぞれにSQLを
    発行するほうが圧倒的に効率的です

    > 項目名、値の組み合わせでデータを持つ、というのは、どのような意味

    それを聞くなら、ご自身のテーブル設計をきちんと表示すべきです
    create table+insert文で例示いただければ
    こうしたらもっと効率的という修正方針も示せるかもしれません。

    キャンセル

  • 2020/02/14 06:13

    なるほど、スピードの件まったく思いつきませんでした。ありがとうございます。

    create table+insert文の例示ですが、他の質問との兼ね合いもあり、ひとまずあいまいな状態で画像だけで質問してしまっておりました。まだ具体的な細部が未定です。にも拘わらずできる限りのご回答を頂いたことに改めて感謝申し上げます。

    キャンセル

+1

彼のタイムラインに
・スレッド1へ投稿されたもの
・ユーザー80が投稿したもの
を流すことを考えます。

その情報を取得すると以下のように「threads」と「comments」をUNIONして

threads → comments という関係だからunionじゃなくてjoinでしょう。

そもそも、同じタイミングで発生するもので無い限りNullは発生します。
正規化されている状態でも、outer join すればNUllは絶対発生するものですから、これらのNull考慮はテーブル設計の段階で決まっている事です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/02/13 10:36

    なるほど。t1へのコメントは横にずっと連結されるのかと思っていました。改めてJOINをいくつか試して勉強しておきます。

    キャンセル

  • 2020/02/13 12:02 編集

    threadsに対して複数のcommentsがある場合、それをjoinすると縦方向(複数行)展開されます。
    これを、threads1行に纏めてcommentsを横方向に展開するような事は、クロス集計と呼びます。
    MySQLだと結構手間(GROUP_CONCAT()が利用できるとは思います)なので、取得した側で編集する事も視野に入れられた方が良いかと思います。

    キャンセル

  • 2020/02/14 06:09

    なるほど、勝手にクロス集計をイメージしておりました。ケースバイケースで手間を考慮し手段を選定できるように早くなりたいです。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.82%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る