ER-диаграмма контент-завода: спроектируй базу с ИИ до первой миграции

Что собираем

Если вайбкодить «контент-завод» сразу, агент быстро создаст одну таблицу posts со множеством несвязанных полей. Потом появятся несколько площадок, версии текстов и метрики — и схема начинает ломаться.

Результат: ER-диаграмма и словарь данных, которые можно передать Laravel-, Supabase- или другому AI-разработчику. Никаких миграций и изменений в базе автоматически.

1. Назови реальные объекты

Для MVP удобно отделить:

• ideas: тема и доказательство, почему она нужна;
• assets: сценарии, исходные изображения, тексты;
• channels: площадка и конкретный канал;
• publications: факт публикации определённого материала в конкретном канале;
• metrics: измерение по публикации и времени;
• campaigns: набор публикаций под одну цель.

Это предлагаемая архитектура, её стоит подогнать под свои сценарии. Если один asset можно публиковать десять раз, нельзя хранить всю статистику прямо в нём.

2. Пример Mermaid

erDiagram
    IDEA ||--o{ ASSET : produces
    ASSET ||--o{ PUBLICATION : used_in
    CHANNEL ||--o{ PUBLICATION : hosts
    PUBLICATION ||--o{ METRIC_SNAPSHOT : measured_by
    CAMPAIGN ||--o{ PUBLICATION : includes
    IDEA {
      int id PK
      string topic
      string evidence_status
    }
    ASSET {
      int id PK
      int idea_id FK
      string kind
      string revision
    }
    PUBLICATION {
      int id PK
      int asset_id FK
      int channel_id FK
      datetime published_at
    }
    METRIC_SNAPSHOT {
      int id PK
      int publication_id FK
      datetime measured_at
      int views
    }

Здесь намеренно не все сущности и столбцы описаны подробно: диаграмма — отправная точка для уточнений.

Что получится на выходе

Промпт архитектору ниже выдаёт проект схемы, с которым можно идти к разработчику или агенту:

• список сущностей и пояснение, почему их нельзя слить в одну таблицу;
• ER-диаграмму Mermaid и словарь данных: поля с типами;
• по каждой связи кардинальность, обязательность и ограничения уникальности;
• вопросы владельцу там, где решение зависит от тебя, включая сроки хранения данных;
• пять сценариев тестовых записей, на которых проявятся ошибки модели;
• план миграций списком, без выполнения.

Базу он не трогает и код не пишет.

Кому подойдёт

Гайд для тех, кто собирает контент-сервис с ИИ-агентом: генератор постов, планировщик публикаций, внутренний инструмент SMM-команды. Схему стоит нарисовать до первой миграции, пока исправление стоит одной правки в диаграмме.

Пример ситуации

Допустим, один сценарий ролика у тебя уходит в Telegram, VK и YouTube Shorts. Если хранить просмотры в карточке сценария, цифры трёх площадок сольются в одно поле, и ты уже не поймёшь, где ролик сработал. В схеме выше у каждой площадки своя запись в publications, а у каждого замера своя строка в metrics. Так видна и история просмотров, и разница между каналами.

Когда схема согласована, правила для агента, который будет писать миграции, собери по гайду Cursor Rules для базы данных: database.mdc без потерь.

Рядом по теме: Псевдокод для вайбкодинга, Промпт-интервьюер: идея → каркас проекта, Нужна ли база данных: решение без лишней сложности, статья «Что такое вайбкодинг» и Чек-лист «Перед запуском» (бесплатно).