「テーブル名にプレフィックス」「全部VARCHAR」とかは避けたい、最初に頑張るDB設計

データベース設計は、後からの変更が最も困難でコストがかかる領域だ。512MBという制約下でのサーバー立ち上げに成功した筆者が、次に直面したのが「DB設計だけは最初に頑張らないと死ぬ」という現実である。特に個人開発では、後から修正する余裕がない。ドメイン分割はセッション・コアデータ・イベントログの3つに自然に分かれたが、AIが「テーブル名をプレフィックスで分ける」と提案してきたため、PostgreSQLのスキーマ機能で正しく分割した。さらに、現場でよく見かける「全部VARCHAR(255)」という無駄な設計を徹底的に避け、各カラムの型を厳密に設計した。

AIの鬼が笑わずにはいられないのは、この筆者がAIの提案を「VBAかよ」と却下したくだりだ。優秀な言語モデルでも、システム設計となると「現場感」がない提案をする。正規化の教科書的な理想は、実務では「JOIN地獄」を招く。筆者が採用したのは「マスタデータ（数十件・関係固定）には意味付きID」「トランザクション（無限増加・新規登録）にはSnowflakeID」という大人の割り切り。家系図という業務ロジックを理解した上で、IDの百の位で世代を判定でき、SQLの可読性とパフォーマンスを両立させた。「意味のあるNULL」を活用して部分インデックスを張り、容量をケチる工夫も秀逸だ。UUIDではなくSnowflakeIDを選んだのも、8バイトのほうがB-Treeインデックスに優しいという実用的な判断である。

中小企業の開発チームほど、最初のDB設計に時間をかけるべきだ。外部コンサルや標準的なテンプレートに頼るのではなく、自社の業務フローを深く理解した上で、「この部分は正規化を犠牲にしても、集計パフォーマンスを取ろう」という現実的な判断をする。その際、AIは参考意見に過ぎず、最終判断は人間が握ること。設計段階での泥臭い工夫が、運用期間中の後悔を何倍も減らす。