データベースのテーブル設計で、使用しないことが多いカラムを別テーブルとするべきか

Question

###前提
II全体の初学者です。
データベースのテーブル設計について学習していて、分からなかったことについて質問します。

###内容
例えば、クラスの生徒を管理するテーブルがあるとして、

・出席番号と名前はすべての生徒のものを登録する
・身長は女子だけ登録する
・将来的に男子の身長を登録することは決してない

というような場合、一般的にはどのようなテーブルを設計することになるでしょうか。

（上記の例は単純化したもので、実際には身長のような項目が複数あったり、男子のみが登録する項目があったりすることを想定しています。）

###考えたこと
1.出席番号、名前、身長を要素とするテーブルを用意し、男子の身長はnullにする
2.出席番号、名前を要素とするテーブルと、出席番号と身長を要素とするテーブルを用意し、女子だけ後者に登録する

のどちらかかと考えています。

---

例が良くない、状況によるなどあると思いますが、ご教授いただけると幸いです。

Comments

[hoshi-takanori]

この辺が参考になるかも？
https://atmarkit.itmedia.co.jp/ait/articles/1703/01/news179.html
https://qiita.com/hmatsu47/items/19c1d6bf636f38234680

[hongou10]

「スーパータイプ／サブタイプ」、知りたかった概念に近いように感じます。知識不足でした。
学習の足掛かりといたします。ありがとうございます。

Answer 1

もし、タイトルでいう「使用」が参照の機会、という意味であれば、単に参照しない（ SELECT に含めない）だけで大きな問題はなくなるでしょう。

ただ、例からすると、タイトルでいう「使用」は特定のフィールドのデータの有無の意味と読めるのでその意味で考えます。

※ te2jiさんの言う通り、質問そのものという意味では「例が良くない」は確かに良くないと思いますが、設計時に検討・想定する状況の例としてのバリエーションを増やすのもいい学習かと思いますので勝手に「こういうケースもある」をいくつかあげようと思います。

一般的な質問の分類でいえば、正規化・非正規化のバランスと、パフォーマンスチューニングの2つの問題のバランスですね。
その観点でいえば、

• 正規化という概念からすれば分けるべき
• クエリをかける際の負荷を考えれば分けないほうが多分軽い（実際は DB のストレージエンジンの特性や、インデックスの貼り方など他の要素に大きく依存するので一概には言えませんが。「身長」列を条件にクエリをかける機会があるかどうかにもよりそうです。）

かなあと思います。

また、例のケースを単純にそのまま読むと、

• 男子のテーブルと、女子のテーブルに分ける

という選択肢もありそうですね。

• テーブル「名簿」： 出席番号、氏名
• テーブル「男子」： 出席番号、男子特有のデータ・・・
• テーブル「女子」： 出席番号、身長・その他女子特有のデータ・・・

とか。

ある程度パフォーマンスをある程度、最近の DB の仕様に寄せて考えれば、データ列にJSON型やXML型を利用することで

• 出席番号、氏名、データ（身長ではなく）

といったようにするケースもありそうですね。
DB次第ですが、JSON型などの列に対するクエリ関数が用意されていることも多いので、行によって格納される要件が様々になりえるならそういった選択肢もあるかもしれません。

いずれにせよ、実際のデータの増減の仕方とアプリケーション上のパフォーマンスのバランスで、何を重視するかによって選択は異なるように思います。

（直接的な回答にならない回答ですみません）

Comments

[hongou10]

使用という言葉は曖昧でした。読み取っていただきありがとうございます。
基礎的な学習で学んだ正規化には当てはまらないよう感じていたので、「正規化という概念からすれば分けるべき」ということが分かったことがとてもありがたいです。
さらに、「データ列にJSON型やXML型を利用」という方法は教えていただくまで知りもしなかったので、大変為になりました。

Answer 2

例が良くない、状況による

例が良くないです。

例えば、身長を定期的に測り履歴が必要。とかになるとデータベースの設計は変わりますし、学年が変わると出席番号も変わる。でも設計は変わります。

場合によっては、名前すら変更の履歴を残さなければならないケースもあります。
最近だと男女すら変更を考慮しなければならないかも。

Comments

[m.ts10806]

履歴書から性別の欄がなくなったんですよね確か。

[退会済みユーザー]

タイトルに対しての回答、誰かしないかなぁ。。。
あまり見たことが無い観点だけど、あり得るのか気になる。

[hongou10]

ご指摘ありがとうございます。おっしゃる通り、その瞬間の情報のことしか考えていませんでした。
データをどのように集めて取り扱うかということを考慮するようにいたします。

Answer 3

例示されている事象とは全然異なり、カラム毎の使用頻度の差が大きい場合ですが。

20年以上昔のとある会員交流サイトでは、会員の基本情報と自己紹介情報を別テーブルとしていました。

このサイトは、チャットのやり取りがアクセスのメインだったため、会員の名前と性別などの基本情報の取得頻度が、自己紹介情報の数十倍でした。

当時、サーバのストレージでスピードが要求される場合でも、SCSIのHDD以上の選択肢がほぼなく、DBシステム内のディスクアクセス量も、パフォーマンスに大きく影響していた為、そういう設計で速度を稼いでいました。

現在のストレージでは、当時より数桁早いSSDが主流になっており、DBシステムも洗練されているため、当時のような配慮は、特殊な事情がない限り、必要ないかと思われます。

Comments

[hongou10]

「使用しない」という書き方は、字義通りに取ると、むしろ回答いただいた場合の意味になりますよね。明瞭な言葉を使うよう気を付けます。
使用頻度の高い情報だけを参照できるようにして処理速度を上げていたというお話、大変興味深いです。ありがとうございます。

Answer 4

要件定義時点で「決してない」としていた事項が「やっぱり必要」となるようなことは常なので、それくらいなら同じテーブルに持っておいて問題ないのでは。

あとは検索の仕方、見せ方次第です。
（それも今後変化する可能性もあるので、あまり情報が散らばるのもよろしくないと思います）

Comments

[hongou10]

ご回答ありがとうございます。
変化に対応するためにテーブルを分けすぎるべきではないということ、参考にいたします。