DBのテーブル設計

はじめに

この前仕事ではじめてDBのテーブル設計を任されました。
どのように？何をしてつくればよいか？何を注意すべきか？を検索したところ長々と注意点を述べているサイトが多数でした。
現代っ子の私は文章が長いとちょっと読む気にならなくて(笑)
そんな私が先輩から教わりつつもどのようなことを注意して設計したかのポイントだけ記録したいと思います。

ポイント

• 命名は人に伝わりやすく、システム屋が使うメジャーなものを使用する
• マスタテーブルと普段使用するテーブルについて
• 容量が大きくならないように長さは適切にする
• テーブルをまたいでも同じ列として使うなら同じ名前にする
• データの整合性が取れるように自動採番のIDを使用する
• 重要度順

命名は人に伝わりやすいもの、システム屋が使う短略単語を使用する

ポイントとして曖昧なことを申しますが人による話でもあります。
1.伝わりやすいよう名前が長くても確実に人に伝わる名前を列名として付けるかなど
2.システムコードの文字数を減らすために分かりやすい短略化した名前を使用するか
上記は本当に好みの問題だと思いますが、
大人数で確実にコーディングしていく開発であれば、一目でわかるように1を採用すべきです。
個人的に開発していくのであれば好きな名前を付けて自分だけわかるように2で開発を進めてもよいでしょう。
2についてのデメリットととしては短略化しすぎたりで、自分以外の人間がそのシステムを触る時に苦労することになるので、おすすめはできません

マスタテーブルと普段使用するテーブルについて

システムDBを触る人ならわかると思いますが、テーブルとしては
M_Member = 従業員・作業員のメンバーリストが入っているマスターテーブル
T_WorkTime = 従業員の労働時間記録テーブル
上記２つのテーブルがあるとします。

M_Memberの列として

「従業員コード、名前、住所、性別、入社日、更新日、退職したか？」
上にあげたものを用意すれば、その従業員が引っ越しや退職しない限りは変更することはありません。
基本的に頻繁に触る必要のないテーブルやコードなど
ほかのテーブルとの結合のためにあるテーブルはマスタテーブルとして管理に使用します。

T_WorkTimeの列として

「従業員コード、日付、打刻時間、帰宅時間」
上にあげたものを用意し、出社のたびに登録すれば毎日使用・更新されるテーブルになります。

大まかにですが２種類の役割の違うテーブルとして分けることで開発の際にマスタテーブルは触らなくてよいなど目印にもなるので役に立ちます。

容量が大きくならないように長さは適切にする

私も細かくは理解していなかったりもしますが
毎日おもちゃが入る箱を6個用意します
□□□□□□
↓そこに毎日３つしかものを入れません
□□□■■■
その日の箱は毎日倉庫に保管し
次の日も同じく新しく6個の箱を使うとします。
そうすると毎日空のただ空間を圧迫する箱が3つあることになります、もったいないですね。
この作業を先ほどのT_WorkTimeテーブルに置き換えます
従業員コード：□□□□11（コードは6桁入るとします）
名前：Aさんとします
Aさんは毎日出勤する人です、週7日打刻するので毎日4桁分の使用していない容量が無駄になるわけです。
システムにもよりますが、将来大きくなることを考えてデータを大きめに設計したりもしますが、初めからそのようなことを考えてやる必要はないので、
現状のベストで開発を進めればいいんじゃないかなと思います。

テーブルをまたいでも同じ列として使うなら同じ名前にする

一方のテーブルの列ではMemberNameという列があり
ほかのテーブルではWorkerNameという列がある
MemberName = WorkerName で使用するなら両方同じ名前でやるということです。
これは当然な話で何言ってんだ！って思うのですが、実際に私も
例1）NumとNumber
例2）InCountとSenderCount
例3）InCountとCountIn
とかでやらかしてたりしていました。

データの整合性が取れるように自動採番のIDを使用する

先ほどのAさんとT_WorkTimeを例にします。
Aさんは5月8日に12時から14時まで2時間も働きました、しかし、
次の日にAさんは突然「従業員コードを99999にするわ」といいマスタテーブルを変えてしまいました。
そうするとAさんがAさんは5月8日に働いたデータを従業員コードだけで管理すると手に入らないのです。
そこで不変のIDを使うわけです、IDを使ってM_MemberとT_WorkTimeのデータを取るのでAさんが働いたデータが取れないことはなくなりました。

重要度順

名前の順番については個人の好みになりますが、
あるテーブルが20列もある状態でよく使う列が19番目にあるとすると、1から19番目を数えてみるのも少ししんどいですね。
ここでは触れていませんがキーの横に普段参照する列を設計して自分や開発者が見やすくするのも効率化にもなります。
そのほかで、列の順番がぐちゃぐちゃですと見にくいし理解しにくいですよね。
入庫管理テーブルがあり
「入庫数、更新日、商品名、担当者、入庫日、商品ID」の順番に列があるとします。
キーになる「商品ID」が一番最後にあるので、一覧でテーブルを見た場合にかなり探すのが大変になります。
ベストな順番は

1. キー
2. よく参照する情報
3. よく参照する情報の補足情報
4. その他の情報情報

にするのがベストではないかな？と思います。

最後に

他の人のがつらつらと書いてて読む気しないって言いましたが私も長くなってしまいました
DB設計を簡単に考えると大きな改修があったときにテーブルからいじらないといけなくなるので、
わかりやすくしっかり考えて、他人に伝わりやすいDBを作成してください。