Quand les gens entendent « 185 tables de base de données », ils imaginent une complexité gratuite. Mais chaque table existe parce qu'un besoin métier l'exigeait.
Voici comment j'ai conçu le schéma Nexural — les décisions qui ont fonctionné, celles que je modifierais, et les modèles qui passent à l'échelle.
La base de données n'a pas commencé comme un schéma géant. Elle a grandi au fur et à mesure que les domaines produit devenaient réels : utilisateurs, abonnements, workflows de trading, fonctionnalités communautaires, analytics, recherche et opérations.
Conception du schéma par phases
Je n'ai pas conçu 185 tables le premier jour. Le schéma a grandi en 7 phases, chacune ajoutant un domaine :
| Phase | Domaine | Tables | Décision clé |
|---|---|---|---|
| 1 | Auth & Utilisateurs | 12 | Supabase Auth + profils personnalisés |
| 2 | Abonnements | 8 | Machine d'état pilotée par webhook Stripe |
| 3 | Trading | 35 | Instruments, positions, signaux, listes de suivi |
| 4 | Communauté | 25 | Synchronisation Discord, logs de modération, réputation |
| 5 | Analytics | 30 | Métriques, rapports, événements de télémétrie |
| 6 | Recherche | 40 | Stratégies, indicateurs, résultats de backtest |
| 7 | Opérations | 35 | Alertes, newsletters, journaux d'audit |
Chaque phase avait son propre lot de migrations. Je n'ai jamais modifié les tables d'une phase précédente pendant le développement d'une nouvelle phase. Cela a permis de sécuriser les déploiements.
Les trois règles que j'ai suivies
Règle 1 : Normaliser tout sauf les chemins chauds
Les données canoniques sont toujours normalisées. \
