🚀
[DB設計]既存テーブルから新規テーブルにデータを切り出す際のやったことと反省点
既存のテーブルから、別テーブルにデータを切り出す作業をしました
その設計に至るまでの思考を書いておく（DBのことだけでなく画面仕様に関することも含む）
背景
- １００カラム以上を持つテーブルの特定のカラムのデータについて改修依頼がきた
- 最近社内でデータモデリングの学習が盛ん
- 私はまだ未着手...
問題だったこと
nullableが多すぎるテーブルだった
- ひとつのテーブルで100カラム持っていて、それらのほとんどがnullable
- またそのテーブルのデータの使われ方によって該当カラムの使われ方が異なっていた
ひとつのカラムでふたつの物事を管理されていた
- xxx日時というカラムで、予定と実績の双方を意味していた
- ステータスカラムとxxx日時カラムの二つのカラムの掛け合わせで実績か予定かを判断していた
ひとつのイベントにまつわるデータを２画面に跨って管理していた
- とあるイベントで入力する値が複数あったが、それらを別々の画面で入力するようになっていた
- とあるイベントに関係ない項目が、イベント関連項目に含まれていた
改善したこと
- DB周り
- 対象カラムで扱っているデータを別テーブルに分ける
- 予定と実績それぞれを管理するテーブルを作成する
- 画面周り
- ひとつのイベントの予定と実績それぞれを入力できる画面を作成した
- イベントに関係ない項目を別箇所に移動した
考慮漏れ
- 予定のデータをログとして持つべきだった
- 予定のデータは複数回編集されることがあった
- 登録→キャンセル→登録という流れを踏むことがあった
- データをinsertのみにして、キャンセルの履歴を追えるようにすべきだった
- 予定のデータは複数回編集されることがあった
いずれ対応したい！！
※追記
予定をログとして残すのではなくキャンセル履歴をログと残す方向で良いのでは
→なので現状の設計は問題なし、必要になったらキャンセル履歴テーブルを追加しよう
参考にすべきだったこと
- イベントとリソースを分けて考える
感想
最近設計に関わることが多くて毎回楽しくやっているが、見落とし？があって悔しい
前も似たような改修したのに、、、まだ頭に定着してないようだ
Discussion