Смиритесь сразу: архитектуры «на века», которую никогда не придется трогать, не существует. Приложения растут, требования меняются, база данных неизбежно эволюционирует.
Это не значит, что на этап проектирования архитектуры БД можно забить. Это значит, что цель этого проектирования не предсказать будущее, а сделать так, чтобы не пришлось менять таблицы по 20 раз за день в разгаре разработки.
От юзкейсов к сущностям
Чтобы минимизировать трение, используем подход, близкий к DDD (Domain-Driven Development). Сначала нужно выявить сущности и связи. Для этого нужны Use Cases: четкий список того, как именно люди будут пользоваться системой. Что происходит после клика на кнопку? Какой объект создается или меняется?
Возьмем файловое хранилище. Юзер взаимодействует с папками и файлами. Это очевидные сущности которые будут у нас в системе. Но если пользователь делится доступом — появляется третья сущность «шаринг», потому что нам нужно где-то хранить уникальные URL и метаданные этого действия.
Или вот пример с типичным блогом: есть юзеры, которые пишут комментарии к постам, а у постов есть категории. Каждая такая логическая единица — это потенциальная таблица.
Механика связей и визуализация
Когда сущности нарезаны, нам нужно определить тип связей. Для этого можно задать простой вопрос: «Как много объектов привязано друг к другу?».
Один автор может написать пачку постов, но у конкретного поста автор всегда один — это связь один ко многим (1:N). В базе это решается просто: нужно добавить колонку
user_id в таблицу постов. Если связь «многие ко многим» (M:N), то мы сразу проектируем pivot-таблицы.Весь этот граф нужно сначала отрисовать в Miro или на бумаге. Просто квадраты сущностей и стрелки с подписями типов связей. Когда схема готова, «прогоните» через неё глазами каждый юзкейс. Данных для ответа API хватает и не нужно городить костыли? Значит, структура жизнеспособна. Здесь, к сожалению, нет универсального уравнения, только декомпозиция и проверка.
Принцип единственной ответственности в данных
Главный маркер плохой архитектуры — нарушение Single Responsibility. Таблица должна отвечать за одну логическую область. В моем проекте EduMixBot я сначала допустил ошибку: запихал настройки самого обучающего курса и настройки Telegram-бота того же курса в одну сущность
courses. В итоге таблица стала multi-responsibility. В итоге пришлось проводить рефакторинг и разносить их, потому что логика курса и логика транспорта (бота) — это разные вещи. Если ваша таблица начинает «знать» слишком много о разных аспектах системы, она превратится в свалку, которую сложно поддерживать.
Ставь 🔥, если хочешь пост про все возможные связи между сущностями/таблицами с примерами.
А если остались вопросы или что-то звучит слишком абстрактно — пиши в комменты, обязательно разберем!
10МДК | ВЕБМастер