Как спроектировать БД MySQL для редактора фотоальбомов?

Question

[Денис Шестоперов]

Есть задание на разработку редактора фотоальбомов (пример).

Пользователь создает некий проект, загружает свои фотографии, создает или удаляет развороты фотоальбома, выбирает шаблон для фотоальбома и вставляет фотографии на шаблон.

Действия пользователя для создания проекта:
1. Выбрать на сайте категорию товара (фотоальбом, фотокарточка, приглашение)
2. Выбрать конкретный товар из категории
3. Выбрать свойства товара и перейти в редактор

Фронтенд разрабатывается на Vue.js, Бэкенд на Symfony 4, общение между клиентом и сервером происходит посредством REST API (HAL+json).

При проектировании такой базы данных мне не хватает собственных знаний, чтобы решить некоторые проблемы:
1. Категории товаров могут содержать разные свойства (фотоальбомы, фотокарточки, приглашения имеют разные свойства)
2. Какие-то свойства могут зависеть друг от друга
3. Я не понимаю, как ПРАВИЛЬНО создавать проект, который передается в редактор

Я построил некоторую базу данных и считаю ее неправильной, так как она содержит в себе много вложенных сущностей, в связи с чем я не могу реализовать адекватное API для общения с клиентом.

Текущая схема БД:

spoiler

Изначально администратор создает в админке новый фотоальбом (таблица photo_book). Таблица photo_book_format нужна для создания вариаций фотоальбома (в ней указывается размер альбома, количество возможных разворотов (photo_book_spread_range), шаблоны для страниц фотоальбома (photo_book_format_layout хранит в себе путь к json-файлу)).
Пользователь на сайте выбирает свойства для фотоальбома (таблица photo_book_project_details) и создает проект (таблица project).
Таблица project_details нужна для того, чтобы связать project и photo_book_project_details.
Таблица spreads - это таблица разворотов. Развороты содержат в себе страницы (page). У страницы есть выбранный шаблон (который в свою очередь относится к вариации фотоальбома (layout из photo_book_format_layout).
Я постарался объяснить как я реализовал эту БД, но, думаю, вы и сами понимаете, что она слишком сложная и запутанная.

Задачей является создать визуальный редактор для фотоальбомов или фотокарточек, которые создаются в админке сайта.

Answer 1

[Dimonchik]

сейчас хипстеры вкладывают такое в носкл и не парятся, пока заказчик от счетов Амазона не заорет

и вы не парьтесь:
1) строите базу как умеете
2) пишете код
3) берете faker и какой-нибудь wrk , проверяете

заодно сразу пишите тесты - уж они-то обычно хорошо отражают бизнес-логику

ну а что непонятно - так это с любой базой будет для нового человека, главное документирование, что у вас получается неплохо

Comments

[Денис Шестоперов]

Благодарю за ответ! К сожалению при такой реализации я столкнулся с проблемой передачи данных посредством API. Пока БД разработана только для одного типа продуктов (фотоальбомов) я уже столкнулся с тем, что смена шаблона для конкретной страницы проекта будет иметь вид: api/v1/project/{id}/spreads/{id}/page/{id}

А вложенность сущностей и того хуже:
Project -> ProjectDetails -> Spreads -> Page -> Layout

Как вы могли заметить мне пришлось для составления ссылки API исключить сущность ProjectDetails

[Dimonchik]

про шаблон интересно, а что мешает посмотреть, как это в препарируемом сайте?

обычно API передает 2-4 параметра, (запись, фотоальюом в вашем случае ) и т.п., остальное здоровенным массивом выгружается из бека и разбрается на фронте

у вас проект и альбом явно взаимоисключаемые сущности - запрашивать можно или то, или то,
второе - пагинация
ну и все (авторизация ведь через куки)

оттолкнитесь от конкурентов

[Денис Шестоперов]

dimonchik2013, авторизация посредством токена в заголовке реквеста, но не суть

не очень хочется выгружать и отправлять постоянно один и тот же огромный массив данных, если я буду лишь удалять один разворот

Поэтому и хочется реализовать что-то более лаконичное

На счет

у вас проект и альбом явно взаимоисключаемые сущности - запрашивать можно или то, или то,

совсем не понял