Когда люди слышат «185 таблиц в базе данных», они предполагают усложнение ради усложнения. Но каждая таблица существует, потому что этого требовало бизнес-требование.
Вот как я проектировал схему Nexural — решения, которые сработали, те, что я бы изменил, и паттерны, которые масштабируются.
База данных не начиналась как гигантская схема. Она росла по мере того, как становились реальными предметные области продукта: пользователи, подписки, торговые процессы, функции сообщества, аналитика, исследования и операции.
Проектирование схемы по фазам
Я не проектировал 185 таблиц в первый же день. Схема росла в течение 7 фаз, каждая из которых добавляла свою предметную область:
| Фаза | Предметная область | Таблицы | Ключевое решение |
|---|---|---|---|
| 1 | Auth & Users | 12 | Supabase Auth + пользовательские профили |
| 2 | Subscriptions | 8 | Машина состояний на основе вебхуков Stripe |
| 3 | Trading | 35 | Инструменты, позиции, сигналы, списки наблюдения |
| 4 | Community | 25 | Синхронизация с Discord, журналы модерации, репутация |
| 5 | Analytics | 30 | Метрики, отчёты, события телеметрии |
| 6 | Research | 40 | Стратегии, индикаторы, результаты бэктестинга |
| 7 | Operations | 35 | Оповещения, рассылки, журналы аудита |
Каждая фаза имела собственный пакет миграций. Я никогда не изменял таблицы из предыдущей фазы во время разработки новой. Это обеспечивало безопасность развёртывания.
Три правила, которым я следовал
Правило 1: Нормализуйте всё, кроме горячих путей
Канонические данные всегда нормализованы. \
