はい、どうも
今、新しいプロジェクトの超超超根本の部分からやっており、テーブル設計などを考えています
テーブル設計ってそんなに頻繁にやることないかもしれませんが、やるとなると、というかやっているとこれってどうしたらいいんだ…と色々と疑問点が出てくるものですね…
今回はそんなテーブル設計の勘所だなーと思ったところがあったので、ちょっと紹介します
皆さんだったらどうするか、考えてみてくださいー
実際のケース
あんまり詳しくはいけない部分もあるので、超はしょって書くのですが、まず背景としては以下のような状態です
- 健康診断の結果が入るテーブルがある
- 健康診断を受ける患者さんの名前・生年月日を保存しておくためのカラムを用意したいと思っている
この時、健康診断のテーブルに患者さんのカラムを入れるかどうかっていうのが問題です
ちなみに皆さんはどう考えますか？
患者さんの名前・患者さんの生年月日を健康診断の結果のテーブルに入れるっていう選択肢もあると思います
一方で、患者さん用のテーブルを用意して、そちらに名前・生年月日を用意するっていう方法もありそうです
どう判断しますかね？
また情報が結構少ないので、どのような情報があれば、判断できそうでしょうか？
考え方
はい、考えてくださった方はありがとうございます
そうですね、まず大前提、ケースバイケースで正解はないと思ってます、が、一応今回のケースで話をしたいと思います
今回は、テーブルを分ける方向で設計しました、要するに正規化ですね
どうしてそうしたかというと、拡張性が高いから & 健康診断 == 患者さん、ではないから です
まず拡張性が高いっていうのは、他に患者さんの情報が増えたとき、項目を追加しやすいってことですね
例えば現状は名前・生年月日だけですが、他にも年齢とか、住所とか増える可能性があったばあいに対応しやすいということです
ただでさえ健康診断の結果が入るテーブルにはいろいろな情報が入ることになります
そこに患者さんの情報が増えていくというのは、情報が正規化されておらず、煩雑さにつながります
あと、健康診断 == 患者さんではないからっていう部分です
ちょっと想像して欲しいのですが、もし仮に健康診断のテーブルの中に、患者さんの名前・患者さんの生年月日のカラムを作成するときのことを考えます
どういうカラム名になるかというと、’患者さん’の名前とか、’患者さん’の生年月日という形で入力しないといけません
なぜなら、もし患者さんというワードを入れないと、名前・生年月日というカラムは、’健康診断の’名前とか、’健康診断の’生年月日という意味になってしまいます
これだと意味が通らないです
そのような理由から、今回は、テーブルを分ける方向で設計しました
まとめ
というわけで、ちょっとテーブル設計の勘所について少しまとめてみました
今回のケースでは、現時点で患者の名前・生年月日しか情報がないとしても、テーブルを分けることにしました
改めて以下のような理由からです
- 患者さんの情報が今後増えるかも
- 正規化しておけば将来の仕様変更にも対応しやすい
- 患者さんの情報を他の機能で使いたくなったときに再利用しやすい
ただあくまでもケースバイケースで、非正規化でスタートもできると思っています
速度優先な場合は、最初は非正規化でスタートすることもありかもですね…！
この辺りの塩梅がやっぱ難しいなぁと改めて思わされました
ではでは、よきテーブル設計ライフをー
