「185ものデータベーステーブル」と聞けば、複雑さのために複雑にしているだけだと思う人もいるでしょう。しかし、すべてのテーブルには、ビジネス要件がそれを必要としたから存在する理由があります。
ここでは、Nexuralスキーマをどのように設計したか——うまくいった判断、変更したい点、そしてスケールするパターンについて説明します。
データベースは最初から巨大なスキーマとして始まったわけではありません。製品ドメインが現実のものになるにつれて成長しました：ユーザー、サブスクリプション、トレーディングワークフロー、コミュニティ機能、分析、リサーチ、運用。
フェーズベースのスキーマ設計
初日から185テーブルを設計したわけではありません。スキーマは7つのフェーズにわたって成長し、各フェーズでドメインが追加されました：
| フェーズ | ドメイン | テーブル数 | 主要な判断 |
|---|---|---|---|
| 1 | 認証とユーザー | 12 | Supabase Auth + カスタムプロファイル |
| 2 | サブスクリプション | 8 | Stripe webhook駆動のステートマシン |
| 3 | トレーディング | 35 | 銘柄、ポジション、シグナル、ウォッチリスト |
| 4 | コミュニティ | 25 | Discord同期、モデレーションログ、レピュテーション |
| 5 | 分析 | 30 | メトリクス、レポート、テレメトリーイベント |
| 6 | リサーチ | 40 | 戦略、インジケーター、バックテスト結果 |
| 7 | 運用 | 35 | アラート、ニュースレター、監査ログ |
各フェーズには独自のマイグレーションバッチがありました。新しいフェーズの開発中に、以前のフェーズのテーブルを変更することは決してありませんでした。これにより、デプロイの安全性が保たれました。
私が従った3つのルール
ルール1：ホットパス以外はすべて正規化する
正規化されたデータは常に正規化された状態を保ちます。
