これは何か
いわゆるマスター系データには「置き場所の分断」という問題がありがちと思っていて、それに対する考察をまとめたものです。
ただ独自考察なので、正しいかどうかは何とも言えず、書籍とかネット上の発表でこのあたりの話まとめてるのあったら教えてほしいです。
とはいえDB-アプリ横断の話になるし、「Webアプリケーションの作り方」的な本だと触れてる暇が無いと思うので、存在してない気も……。ネットの記事でも見たことがない……泥臭い現場の知恵系の話ですからね。
マスター系データとは何か
マスタデータの主な特徴
- 変更が少ない静的な情報で、安定性が求められる
- 企業全体で共有され、多くの部署にわたり一貫したデータ
- ビジネスプロセスの効率化を実現する基盤となる情報
引用元:
話の発端
これまで
- 零細レガシー企業（自社サー）
- 零細ベンチャー（自社サー/受託両方やってたけど受託メイン）
- 零細レガシーではないけどなりそうな気配のある現職（受託メイン）
と3社経験して、どの会社でも、「中途半端にマスター系データがDBとアプリ側に分散していて処理追うのがきつい！バグの温床になっている！」 という問題と遭遇しました。
（自分はPHPerなので）PHPファイル内で巨大連想配列で直書きされているならまだ可愛い方で、大元はCSV,JSONファイルなんて例も珍しくはなく、他社からファイル連携（という名の他社からのサーバー接続からの自動/手動のアップロード作業） であったりとか、非エンジニアが元データ作って渡してくる とかが絡んでて、フローごと変えるコストが滅茶苦茶高いケースもありますね。
独立した小データならまだいいんですが、リレーションがあって本来DBのテーブルとして切り出さない内容なのにアプリ側で持っているもんだから、"●●●Id"プロパティがデータに埋め込まれている なんてのもよくある話。別タブやウィンドウでコードとDBの値見て脳内JOIN……うーん！😑😑😑😑😑
結論
- 理想としてはDBに全部あった方がいい（大前提）
- 諸々の技術革新で昔に比べれば改善したものの、未だDBの変更よりアプリの変更の方がコストが安い／難易度が低いという現実 があり、そこが運用面に重くのしかかっていて発生している。
- とことん運用都合（主導）であり、純粋なエンジニアリング理論とはほど遠いところの話である。現場の知恵的な。
- 肌感としては「仕様として枯れている」、「そのアプリケーションの中でコア」、「管理画面やAPIを通して動的に変更する必要がある」ものはDBに置くのがいいと思います。（というか置かざるを得ない）
- 開発や運用初期で仕様自体が全く安定せず、変更はデプロイ時のみでOKという場合はあえてアプリ側に留めて頑張ってカバーするというのも正直言ってアリ。（なお移行する暇なくて割れ窓になる模様😩）
- 他社や非エンジニアからファイルを貰わずに済むよう、管理画面や入力フォーム等を整備したり、ファイルからDBに取り込む処理を書く等、泥臭く整備するしかない。そもそもそんな自社orクライアントにお金がないからこんなことになっているし、改善したくてもお金の問題で手をつけられないことが多いのだが……