Рекомендации по логике базы данных, необходимые для сохранения и отображения страниц с подстраницами в Laravel / PHP / MySQL

Это первое приложение, которое я создаю (на Laravel), которое не является «делом» из учебника, и я ищу лучший способ реализовать логику базы данных.

Я создаю приложение, в котором пользователи могут создавать страницы и подстраницы. Однако существуют различные типы шаблонов страниц, такие как:

• Аудио: (для встраивания Soundcloud)
• Видео: (для встраивания YouTube)

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

Структура внешнего интерфейса URL будет выглядеть так:

website.com/username/mixes/ — Показать список миксов

website.com/username/mixes/name-of-mix — перейти непосредственно к каждому миксу

В админке пользователь пойдет по пути

1. Добавить новую страницу (простая ссылка)

2. Выберите шаблон (например, аудио или видео)

3. Выбирает аудио шаблон и называет его Миксы (front-end
   website.com/username/mixes)

4. Возвращает на вновь созданную (но пустую) страницу миксов

5. Пользователь нажимает «Добавить новый аудио элемент»

6. Создает новый аудио элемент под названием «Название микса»

7. Это заставляет предыдущую первую часть слага быть / mixes / и
   затем добавляет «имя смеси» в конце.

8. Пользователь может повторить это несколько раз для страницы Mixes.

Все вышеперечисленное я могу реализовать (в рамках контроллеров в Laravel).

Проблема, с которой я сталкиваюсь, заключается в том, каков наилучший / самый чистый способ реализовать это в базе данных?

Должен ли я …

ВАРИАНТ ПЕРВЫЙ — — — — — — — — — — — — — — — — — — — —

Сохраните каждую страницу и подстраницу в модели страниц и шаблонах ссылок (если подстраница) из нее, например:

Целевая страница (website.com/username/mixes)

новая страница:

- id: 1
- user_id: 1
- format: audio
- format_id: null
- template: audio_landing
- title: Mixes
- slug: mixes

Одна страница (website.com/username/mixes/name-of-mix)

Когда это будет сохранено, он создаст страницу, а также создаст отдельный аудио элемент

новое аудио:

- id: 6
- user_id: 1
- title: Name of mix
- embed_code: 7654365

новая страница:

- id: 2
- user_id: 1
- format: audio
- format_id: 6
- template: audio_single
- title: null (title is on the audio model)
- slug: mixes/name-of-mix

Тогда, по моему мнению, я бы назвал website.com/{username}/{slug}

Запрос будет сканировать только через модель User (для имени пользователя), затем модель Pages, останавливается, когда найден правильный слаг, затем ссылается на связанную модель Audio и создает представление для этой страницы. Это (я думаю) было бы более быстрым и менее интенсивным (на MySQL) способом получения информации о странице.

Правильно ли я думаю, из модели страниц, я могу использовать «format: audio«искать аудио модель иformat_id: 6«чтобы соответствовать модели»id: 6»

ВАРИАНТ ВТОРОЙ — — — — — — — — — — — — — — — — — — — —

Сохраните страницы в Pages, затем сохраните подстраницы в модели Audio.

Целевая страница (website.com/username/mixes)

новая страница:

- id: 1
- user_id: 1
- template: audio_landing
- title: Mixes
- slug: mixes

Одна страница (website.com/username/mixes/name-of-mix)

Это сохранит непосредственно в аудио модели

новое аудио:

- id: 6
- user_id: 1
- template: audio_single
- title: Name of mix
- embed_code: 7654365
- slug: mixes/name-of-mix

Тогда, по моему мнению, я бы назвал website.com/{username}/{slug}

Недостатком (я думаю) является то, что запрос должен был бы искать через модели «Страницы», «Аудио», «Видео», «Концерты», «Блог», «События» и т. Д., Прежде чем он обнаружил правильный слаг. Это, я полагаю, будет очень интенсивным в базе данных каждый раз, когда загружается запрос страницы?

Извините, что побежал немного, любой совет будет очень кстати.

Джек.