Made on
Tilda
02
Модуль 1 · Занятие 1
Переводим идею MVP в модель данных и сценарий работы пользователя
Выбор кейса
| Кейс | Сущности | Сложность |
|---|---|---|
| Заявка / обратная связь | заявка | ★ |
| Запись на услугу (сквозной) | клиент, услуга, заявка, статус | ★★ |
| Регистрация на мероприятие | участник, мероприятие, регистрация | ★★ |
| Мини-каталог с заказом | товар, заказ, позиция заказа | ★★★ |
| Личный кабинет | пользователь, профиль, сессия + авторизация | ★★★★ — за рамками |
Назначение MVP в одну фразу
Шаблон
[кто] может [что сделать], чтобы [результат], а [кто] видит [что].
Пользовательский сценарий
01
Заходит на страницу
02
Смотрит услуги
→ услуга
03
Заполняет форму
→ имя, email, телефон, дата
04
Отправляет
→ согласие
05
Прослойка проверяет и сохраняет
→ статус new, created_at
06
Видит «Заявка принята»
07
Администратор меняет статус
08
Клиент получает услугу
→ done
От сценария к сущностям
| В сценарии | Сущность | Поля |
|---|---|---|
| посетитель | clients | id, name, email, phone, created_at |
| услуга | services | id, code, title, price, is_active |
| заявка | requests | id, client_id, service_id, preferred_date, status, created_at |
| статус | — поле, не сущность | new · confirmed · done · cancelled |
ER-диаграмма
clients
1 : N
requests
N : 1
services
Разбор ошибок
| Ошибка | Где ломается | Как правильно |
|---|---|---|
| Одна таблица на всё | Клиент записывается заново при каждой заявке, его имя и телефон расходятся по опечаткам | clients, services и requests по отдельности |
| Статус отдельной таблицей | Лишняя связь ради четырёх значений, которые никогда не меняются | Поле с ограниченным списком значений |
| Внешний ключ на стороне «один» | Список заявок внутри клиента ломается на второй же заявке | client_id и service_id — в таблице requests |
| Нет id и created_at | Не на что сослаться и нечем отсортировать: непонятно, какая заявка раньше | id и created_at есть у каждой сущности |
| Поля кириллицей и с пробелами | «Желаемая дата» не совпадёт с именем переменной в форме Tilda на уроке 4 | Латиница, нижний регистр, snake_case |
JSON-структура
Отправляет форма — плоско
{ "name": "Анна", "email": "anna@example.com", "phone": "+79123456789", "service": "Консультация", "date": "05.10.2026", "consent": "yes" }
Ложится в БД — по таблицам
{ "client": { "email": "anna@example.com", "name": "Анна" }, "request": { "service_id": 1, "preferred_date": "2026-10-05", "status": "new" } }
Имена полей — латиница, snake_case. Они станут именами переменных в форме Tilda на уроке 4.
Мини-артефакт урока 2
Вопросы для самопроверки
01
Как по сценарию понять, что нужна отдельная сущность?
02
На какой стороне связи 1:N находится внешний ключ?
03
Почему статус лучше хранить как ограниченный список?