Антипаттерн: "Сначала MVP — потом нормальная схема"

Частая ошибка при старте проекта — отложить продумывание структуры базы «на потом»:

«Сейчас сделаем быстро MVP, а потом приведём БД в порядок».
И вот что часто происходит:
– MVP превращается в продакшн без переработки схемы.
– Костыли начинают множиться.
– Появляется технический долг, который сложно погасить: миграции становятся болью, связи — запутанными, а данные — ненадёжными.

Типичные симптомы:
— nullable-поля без нужды
— дублирование данных
— универсальные таблицы вроде entities или attributes
— "магические" значения в enum-полях
— отсутствие внешних ключей и индексов

Как избежать:

1. Минимум нормализации — с самого начала. Даже для MVP важно заложить понятную структуру.
2. Используй миграции сразу. Даже если это скрипт в папке migrations/, а не полноценный tool.
3. Заведи ER-диаграмму. Она не обязана быть идеальной, но уже поможет избежать хаоса.
4. Смотри в будущее. Планируешь рост? Подумай о расширяемости схемы.
5. Не стесняйся рефакторить. Лучше на раннем этапе изменить структуру, чем через год бояться сломать прод.

👉 MVP не должен значить "без архитектуры". Плохая схема — это замедление развития и боль на каждый новый фичереквест.

Сохрани, если строишь новый проект — пригодится.

#db

👉 [club79831840|@Bookflow]