Проектирование БД:
Инженерный триумвират
Почему при создании фундамента данных субъективные понятия «Просто» и «Хорошо» уступают место жестким инженерным императивам: Очевидно, Отказоустойчиво и Наглядно.
Очевидно
Вместо абстрактной простоты — самодокументируемая структура. Схема должна читаться как открытая книга.
- Прозрачные связи (FK)
- Семантические имена
Отказоустойчиво
Данные невозможно испортить. База сопротивляется некорректному вводу на уровне ядра.
- Строгие Constraints
- Транзакции ACID
Наглядно
Структура отражает реальный бизнес. Виртуальные таблицы (Views) для мгновенной аналитики.
- Бизнес-сущности
- Читаемые отчеты
От субъективности к инженерии
Как не стоит делать
Принцип «Просто»
Свалить все данные в одну таблицу Orders_All_Final_v2. Это кажется простым вначале, но дублирование данных и аномалии обновления превратят проект в кошмар.
Инженерный подход
Принцип «Очевидно»
Нормализация данных и четкое разделение ответственности. OrderHistory отдельно, PaymentStatus отдельно. Связи через явные внешние ключи.
Иерархия применения
Work-flow| Этап работы | Принцип | Конкретные действия |
|---|---|---|
| Схема (Архитектура) | Очевидно | Логичные связи, понятные любому новому разработчику без документации. |
| Целостность данных | Отказоустойчиво | Установка Foreign Keys, Indexes, Check Constraints. Бронирование ядра. |
| Доступ и API | Наглядно | Создание Views и маппингов, превращающих сырые данные в готовые бизнес-ответы. |
Резюме для архитектора
База данных — это фундамент. Если данные «протухнут» или связность нарушится, никакая красота интерфейса не спасет проект. Держите в голове Отказоустойчивость как главный приоритет.