【要約】動的スキーマを 1 テーブル × 1 endpoint で扱う設計について [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者は、業務要件の変化に伴い、頻繁に発生するデータ構造の変更に苦慮していた。従来のRDB設計では、フィールドの追加ごとに以下の問題が発生していた。
- ・新しいオブジェクト追加のたびに、テーブル定義やCRUD API、UIの再実装が必要になる。
- ・フィールド追加のたびに、本番環境でのDB migrationが必須となる。
- ・類似した構造のCRUDコードが、オブジェクトの増加とともに増殖し続ける。
// Approach
開発者は、スキーマの柔軟性とRDBの堅牢性を両立させるため、以下の手法を採用した。
- ・PostgreSQLのJSONBを活用し、全ての業務オブジェクトを1つのテーブルに集約する。
- ・スキーマ定義をYAML形式で外部管理し、起動時にメモリ上のレジストリへ登録する。
- ・FastAPIのパスパラメータを利用し、1つのエンドポイントで全オブジェクトの処理を完結させる。
- ・Pydanticのcreate_modelを用い、YAML定義から実行時にバリデーションモデルを動的に生成する。
// Result
開発者は、オブジェクトの種類が増加しても、CRUD APIのコード量を一定に保つことに成功した。
- ・オブジェクトの種類が数十種類に達しても、APIの実装量は数百行に抑えられた。
- ・スキーマ変更時にDBのmigrationが不要となり、開発スピードが向上した。
- ・業務が定着した際に、専用テーブルへデータを移行できる「昇格」の道筋を確保した。
Senior Engineer Insight
> 実戦投入において、この設計は「スピード重視の初期フェーズ」で極めて高い価値を発揮する。しかし、大規模な集計や複雑なリレーションが求められるフェーズでは、JSONBのクエリコストがボトルネックとなる。重要なのは、この記事が提唱するように「柔軟から堅牢へ」の移行パスを、Repository層の抽象化によってあらかじめ設計に組み込んでおくことだ。単にJSONBに逃げるのではなく、RDBの正規化への退路を確保している点に、実戦的な審美眼を感じる。