Перейти к содержанию

Рекомендации по разработке и введению реляционной

I. Император дарует ТЗ: анализ требований

1. Не бывает хорошей БД без ясной цели.

Прежде чем открывать священную консоль CREATE TABLE, зафиксируй:

  • Какие процессы должна поддерживать БД (учёт, отчёты, аналитика, интеграция с ботами/сайтами и т.д.).
  • Кто такие «фракции»:
    • пользователи (роль: админ, оператор, аналитик);
    • внешние системы (боты, сервисы, отчётность).
  • Какие у них «истории боя»:
    • какие данные вводят;
    • какие отчёты/выборки ждут;
    • какие действия совершают.

2. Очищение ереси в требованиях.

Исключи противоречия и размытие:

  • У каждого атрибута — чёткое назначение и тип (дата, число, строка, флаг).
  • Лишние поля «на всякий случай» — ересь, ведущая к хаосу в отчётах.
  • Всё неоднозначное — запиши в отдельный список вопросов к заказчику (или самому себе как аналитику).

II. Священная схема: концептуальное и логическое проектирование

3. Сначала — карта Сегментиума (ER-диаграмма).

  • Определи сущности (таблицы): User, Group, Order, Course, Unit, Equipment — как планеты и флотилии.
  • Для каждой сущности:
    • ключевой идентификатор (ID);
    • основные атрибуты;
    • связи (1:М, М:М, 1:1).

4. Нормализация — экзорцизм дублирующихся данных.

  • Минимум до 3НФ:
    • нет повторяющихся групп полей;
    • каждый неключевой атрибут зависит от ключа и только от ключа;
    • выноси справочники (статусы, типы, роли) в отдельные таблицы.
  • Не храни одно и то же в трёх местах — это как позволить культу Хаоса жить в каждом модуле.

5. Логическая схема — Кодекс Астартес для таблиц.

  • Имена таблиц и полей:
    • без пробелов, осмысленные: student, course, enrollment;
    • единый стиль: snake_case или camelCase, но один на всю БД.
  • Для связей М:М — отдельные таблицы-мосты: student_course, user_role.

III. Ключи и ограничения: печати Империума на данных

6. Первичные ключи — генокод каждой записи.

  • В каждой таблице один первичный ключ (PK).
  • Либо суррогатный (INT/BIGINT, SERIAL/IDENTITY, UUID), либо осмысленный, но:
    • он не должен изменяться;
    • он должен быть уникален во времени.

7. Внешние ключи — цепи, удерживающие целостность.

  • Для всех связей 1:М и М:М — FOREIGN KEY с ON UPDATE/ON DELETE:
    • RESTRICT / NO ACTION — когда удалять нельзя;
    • CASCADE — когда логично удалять «подчинённых»;
    • SET NULL — когда потеря связи допустима.
  • Без внешних ключей БД быстро превращается в мир после нашествия Тиранидов.

8. Ограничения — инквизиция в таблицах.

  • NOT NULL — там, где поле обязательно;
  • UNIQUE — для логинов, e-mail, кодов;
  • CHECK — для значений флагов, диапазонов дат и т.п.
  • Чем больше проверок на уровне БД, тем меньше хаоса в коде приложений.

IV. Индексы и производительность: техножрецы Оптимизации

9. Индексы — благословлённые сервоприводы запросов.

  • По умолчанию индекс есть на PK.
  • Добавляй индексы:
    • на поля, часто участвующие в WHERE, JOIN, ORDER BY;
    • на внешние ключи в таблицах со множеством строк.
  • Не злоупотребляй: каждый лишний индекс замедляет INSERT/UPDATE/DELETE.

10. Профилирование запросов — обращение к машине предсказаний.

  • Используй EXPLAIN, EXPLAIN ANALYZE (или аналоги) для тяжёлых запросов.
  • Ищи:
    • полные сканы больших таблиц там, где можно использовать индекс;
    • слишком сложные JOIN’ы и подзапросы.
  • Оптимизируй запросы до того, как пользователи решат вызвать экзорцистов.

V. Архитектура и среды: «имперский флот» окружений

11. Разделение миров: DEV, TEST, PROD.

  • DEV — мир экспериментов, здесь можно устраивать «еретические» миграции.
  • TEST/QA — мир боевых испытаний:
    • данные максимально близки к реальным (обезличены);
    • проверки производительности и отчётов.
  • PROD — Священный Трон:
    • только проверенные миграции;
    • доступ строго по ролям.

12. Миграции — литании изменения схемы.

  • Используй систему миграций (Liquibase, Flyway, встроенные миграции фреймворка или свои скрипты с версионированием).
  • Каждая миграция:
    • имеет номер/версию;
    • описывает чёткие изменения (создание/изменение/удаление таблиц, индексов, ограничений);
    • может быть выполнена повторно на пустую БД (idempotent, по возможности).

VI. Ввод данных и запуск: вывод БД на линию фронта

13. Инициализация — заселение Империума.

  • Подготовь скрипты:
    • создания схемы;
    • заполнения справочников (роли, статусы, типы);
    • вставки тестовых данных для демонстраций.
  • Для продакшена:
    • отдельные скрипты детерминированной инициализации;
    • логирование всех массовых операций.

14. Миграция со старых систем — крестовый поход данных.

  • Определи источник истины (какая система главная).
  • Разработай ETL-процесс:
    • извлечение → очистка → преобразование → загрузка;
    • лог ошибок и отчёт по «потерянным» или проблемным строкам.
  • После миграции — обязательная проверка:
    • выборочные сверки с исходными отчётами;
    • согласование с заказчиком.

15. Поэтапный запуск — не штурмуй Терру с одного залпа.

  • Запускай подсистемы по очереди:
    • сначала справочники и базовые операции;
    • затем сложные отчёты и интеграции.
  • На каждом этапе:
    • откатный план (rollback или компенсирующие скрипты);
    • точка резервной копии.

VII. Безопасность и права: Ордо Дата-Инквизитора

16. Роли и права — +герб Империума на доступах.

  • Создай роли в СУБД:
    • db_admin — настройка схемы, миграции;
    • app_user — доступ к нужным таблицам только через минимальный набор прав;
    • analyst — доступ на чтение к определённым представлениям/таблицам.
  • Приложения подключай под отдельными пользователями, а не под «суперадмином».

17. Принцип минимальных привилегий — «ни байта лишнего».

  • Каждой роли только то, что ей нужно:
    • запрет прямого DELETE из критичных таблиц, если можно логически помечать записи;
    • запрет DROP/ALTER для всех, кроме администраторов.

18. Аудит и логирование — хроники Священного Архива.

  • Включи логирование:
    • неуспешных подключений;
    • критичных DDL-операций (ALTER, DROP);
    • массовых изменений (bulk update/delete).
  • Храни логи достаточно долго, чтобы найти «еретика», взорвавшего таблицу.

VIII. Резервное копирование и мониторинг: чтоб Империум не пал

19. Бэкапы — эквивалент эвакуационного флота.

  • Настрой регулярные резервные копии:
    • полные (например, раз в день/неделю);
    • инкрементальные/дифференциальные (между полными).
  • Периодически проверяй восстановление:
    • просто наличие бэкапа без тестового восстановления — вера без проверки, а значит ересь.

20. Мониторинг — око Астрономикона.

  • Следи за:
    • нагрузкой на CPU/IO;
    • ростом объёма данных;
    • временем выполнения ключевых запросов;
    • ошибками подключений.
  • Вводи пороговые уведомления — чтобы о проблеме узнать раньше, чем «всё упало».

IX. Документация и обучение: Кодекс для живых людей

21. Документация — не священный свиток «для галочки».

  • Зафиксируй:
    • диаграмму сущностей и связей;
    • назначения ключевых таблиц и полей;
    • правила использования (что и как заполняется);
    • структуру ролей и прав доступа;
    • стандартные отчёты и запросы.
  • Обновляй документацию при изменениях схемы (проводи «ренессанс», а не оставляй древние свитки времён бета-версии).

22. Обучение пользователей — наставление рекрутов.

  • Сделай краткие инструкции:
    • как правильно вводить данные;
    • какие отчёты и где искать;
    • чего делать нельзя под страхом «экскоммуника» (например, править ключевые справочники без согласования).
  • Лучше короткие, понятные руководства и скриншоты, чем 200-страничный том, который никто не откроет.

X. Краткий «Кредо» Имперской БД

  1. Схема рождается из предметной области, а не из UI.
  2. Целостность — в БД, а не только в коде приложения.
  3. Индексы и ограничения — твой болтер против хаоса данных.
  4. Бэкапы и тест восстановления — твой спасательный челнок.
  5. Документация и обучение — способ передать знание дальше, когда нынешний Магос устанет.