База без боли: 7 правил схемы, которая не ломает auth, rls и рост данных

База без боли: 7 правил схемы, которая не ломает auth, rls и рост данных

Если схема сразу кривая, потом страдают запросы, миграции и права доступа. Для Supabase это особенно заметно: плохой design быстро превращает auth и rls в набор костылей.

— Разделяй сущности по смыслу: users, accounts, sessions, events, logs. Не складывай всё в одну «универсальную» таблицу.
— У каждой таблицы должен быть явный владелец строки и понятный ключ для join’ов.
— Имена колонок делай стабильными: без двусмысленных status, type, data, value.
— Типы выбирай узкие: uuid, timestamptz, boolean, numeric только там, где это реально нужно.
— Сразу продумай уникальность и внешние ключи: они дешевле, чем ручная проверка в приложении.

Для rls полезно проектировать таблицы так, чтобы политика читалась в одну строку: user_id = auth.uid() или через membership-таблицу. Если доступ надо вычислять через 3 join’а, схема уже просит пересборку.

Отдельно держи «горячие» таблицы событий и «холодные» справочники. Не мешай audit, аналитику и рабочие данные в одном месте: так проще индексировать, архивировать и не убивать основные запросы.

Хорошая схема — это не красота в ER-диаграмме, а предсказуемые join’ы, простые политики и миграции без сюрпризов. Если сомневаешься, оптимизируй не таблицу, а границу ответственности.