どうも、記事書くのにちょっとはまっちゃった人です
今日は「本当にあったやらかしDB設計①【R無しRDB】」に続いてまたびっくりしたことを紹介します
#囚人番号テーブル
割とみんな使ってしまっているのではないでしょうか
どういうことかというと、「XXX001」「XXX002」「XXX003」のようにテーブル名に囚人番号を付けている、ということです
###何が悪いの？？
皆さん、クラス名や関数名を付けるときに悩んだ経験はありませんか？
誤用を避けるためや可読性を向上させるためにも名前付けって大事ですよね
これは**テーブル名にも同じことが言えます**
自分の子どもが居るとして、子どもの名前に「XXX001」って付けますか？？
少なくとも何かしらの意味を持った名前にするんじゃないかなと思います
(もしくは好きな人の名前とか)
意味の無い名前ほど意味のわからないものは無いです(だって元々意味がないんだから…)
###問題
テーブル名を適当に付けるといろいろ厄介なことが起こります
-
テーブル名を見ても何のデータが入っているか全くわからない
テーブル名を見ただけでもある程度は中身のデータまで想像できるようにするべきです -
誤ったクエリーを書いてしまう
特に囚人番号テーブルを使っていると似通ったテーブル名になってしまうことがあり、間違いの種になることがあります
他にも、クエリーを書くときにテーブルに別名を付けて書くときには「t1」、「t2」のような使い捨てのような名前ではなく、意味の伝わる言葉を使うべきです
別名はテーブル名の省略系として記述すべきであり、一番良いのは別名を付けなくてもクエリーだけで意味が伝わることです -
データと関係の無い、無駄に難しい謎の命名規則が生まれてしまう
これはかなり厄介な問題です
命名規則というのはわかりやすさのために考えることですが、囚人番号テーブルのような構造の命名規則を考えてしまうと逆効果になってしまいます
下手をするとテーブル名の桁溢れ、なんてことも起こります
テーブル名の命名規則はシンプルなものにするべきです
###原因
なぜこのようなことが起こってしまうのか、原因は単純です
数を数えて順番に並べようとしてしまっています
###解決方法
######テーブルをグループ分けしよう！
- まずはどのようなデータが必要なのかを洗い出します
- データをグループごとに分けます
(顧客、商品、注文などなど) - グループ内で適切にテーブル分けを行います
- テーブル名をグループと紐づいた名前にします
これを行うことで、グループ別にテーブル名を決めることができ、テーブル名だけでどのグループに所属するどのようなデータなのかが非常にわかりやすくなります
この工程はエンティティの抽出、論理設計、物理設計、正規化と呼ばれる部分を簡単に並べたものです
でもなんかこれだけなら意外と簡単そうじゃないですか？
そう、実はDB設計ってそんなに複雑じゃないんです
もちろん、扱うデータによっては複雑になってしまうこともあるんですけど…
######テーブルの命名規則を変えない
は？どゆこと？解決方法じゃないの？？？ってなると思います
残念ながら、既存の囚人番号テーブルに対する明確な解決策はほぼありません
なぜかと言うと、囚人番号テーブルは根本的にDB設計が間違っていることがあるからです
データをグループ分けしていない、外部キーを適切に使っていない、正規化が中途半端、などなど…
データのグループ分けが正しくできていれば名前を変えるだけで良いのですが、それができていないから囚人番号テーブルになっているんです！！！
運よく「設計はちゃんとしてるけど命名規則だけが何か変」というパターンに当たることができれば解決できますが、それ以外のパターンだとテーブル構造から変えることになってしまうので中々現実的ではないんですよね
なので、開き直ってテーブルの命名規則は変えずに、中身ごと見直そう、というタイミングで設計しなおす他ありません
#まとめ
- 自分の子どもの名前を決めるように慎重にテーブル名を考えろ
- 関数名にはうるさい人はテーブル名にもうるさい人になれ
- いい加減な設計をするな
囚人番号テーブル、どれだけ罪深いか分かって頂けたでしょうか…
DBは一度設計してしまうと後から修正が効かないことが多々あります
最初の一発目、データが空っぽの状態で正しく設計をし、正しく命名することはめっちゃ重要なんです