久しぶりの更新です
先に言っておきますが、この記事は「こうしましょう！」という対応方法の話ではなく、単に取り組み方を憶測していく駄文です
動機
最近、オンプレで動いてる20年モノの業務系パッケージシステムを扱うことがありまして、このシステムのDBの作りがなかなか…
思いつくだけでざっくり挙げればこんな感じ
参照系、更新系とかで分かれてない
1つのPostgresで動いてる
基本的にカラムはtext型
integerもbooleanもtext型
trueって文字列が値として入ってるカラム名は単語の略
customer → cust といった感じ
↑のならまだ分かるけど、名前からでは用途がわからないものもあったりする予備カラムたくさん
そしてめっちゃ使ってる（テーブルによっては予備が余ってない…）
しかも入る値はサーバ設置先のお客さんによってまちまち汎用テーブルがある
PKであるべきものがPKになってない＆Null許容
↑のせいで外部キー参照できない
お客さんによって専用のDBや追加カラムが存在する
アンチパターンの塊のようなDB
ある意味研修とかで使えそう
で思ったのが、もしこのシステムを新しく作り直すことになって、 「顧客のデータは1つのDBにまとめて、既存からも乗り換えられるようにするぞ！」ってなったらどう取り組んでいけば良いのかなと…
こういう秘伝のタレを美味しく作り直すのってどうすればいいんだろうか？
考えないといけないこと
アプリケーション側の方針でDB設計の方針も違ってくると思うが、、、
何のデータをRDBに持たせるようにするか
NoSQLを導入してそっちに持たせるようにしたり…
データの型、サイズ
少なくとも、何でもかんでもtext型はイカン
既存からデータ移行する方法
どうConvertさせるのが良いのか？
プログラム的解決を図れば大変そうだけど何とかなりそう保守に優しいテーブル設計
予備カラムだったものは用途ごとで名前付け
正規化の意識ダイジ拡張可能なテーブル設計
予備カラムは同じ負債を抱えることになるので作るべきでない
Deployのフローや体制の組み方で、テーブル定義に変更が発生しても安全性が担保できる？
この辺りは世にあるDB設計の知識を活用すれば何とかなる領域な気がする…が、
お客さんによって使い方が違うカラムや、特定のお客さんのDBでのみ存在するテーブル
これはどうしていくのが正解？
システム刷新によって「使えなくなります」は解約に繋がりそう
かと言って共通機能としては使うケースが限られ過ぎている場合があるカスタマイズ具合が激しい顧客は、現状維持で別途保守していかざるを得ない？
お客さん別で専用のテーブルとか作るようにすると、一応何とかなりそうだけど保守面に影響でそう
こういう部分が負債として大きいからシステムの刷新て踏み切りにくいのかなぁと思う
どう進めていくべきなのか？
ざっくりと、以下の感じで進めることになりそうな気がする
現状把握
正規化できるところの洗い出し
予備フィールドの使い道状況
汎用テーブルの使われ方
顧客別カスタマイズ状況コアとなる機能のテーブル設計
正規化しやすそうな機能からテーブル設計していく
機能ごとで切り離しにくい部分は、切り離す粒度を変えればできるのか？
まとめ（まとまってない）
どうするのがいいんだろう…
また何か考えることがあったらこの記事に追記していこうと思う