Как правильно генерировать меню навигации и организовать сущности данных?

Question

[RNB]

Прошу совета как правильно организовать данные и связи между ними.
Я разрабатываю стандартный веб-проект. В качестве основы один из MVC фреймворков. Для простоты я опущу все сложности.

Основная масса данных это Категория и относящиеся к ней Статьи. Связь: Categories hasMany Articles.
У Categories есть поля: id, name У Articles:id, category_id, title
На основе этих данных строится меню на сайте и вся навигация.

Теперь мне требуется добавить 2 новых типа данных в базу: проекты и люди работающие над этими проектами.
В базе они будут отражены как Projects и Persons. Projects HABTM Persons
Projects: id, title. Persons: id, project_id, name, surname.

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

Мои варианты:
1. Очевидно неподходящий (на мой взгляд): отказ от дополнительных таблиц и попытка запихнуть новые сущности в пределы Articles. Это несомненно плохой вариант, требует дополнительных полей и т.д. Чем больше будет новых сущностей... ну вы поняли.
2. (используется сейчас). Сущности Projects добавлено поле category_id и связь belongsTo Categories. А Categories hasMany Projects.

Раньше меню строилось по принципу: Выбрать все Categories и к каждой выбрать все Articles.
Теперь пришлось изменить на: Выбрать все Categories, к каждой выбрать все Articles, к каждой выбрать все Projects.
Фактически же Projects есть только у одной из Categories.

Минусы данного решения: когда в проекте появятся ещё больше новых сущностей, то придётся добавлять и добавлять (до бесконечности) дополнительные выборки из базы чтоб построить меню.

Вопрос: как решить эту задачу правильно?

Comments

[Алексей]

в проекте только 1 человек участвует ?

[Алексей]

Обзовите Projects в Articles2 с точно такойже связью к категории. А то не понятно в чем их существенное отличие.

Что у вас "главнее", проекты или статьи ?

[RNB]

Это странный совет. Зачем мне переименовывать эту сущность?

Answer 1

[Алексей]

Вобщем я бы предложил такое решение:
Есть таблица menu с полями id, title, category_id type
Есть таблица связующая таблица categories с полями id, content_id, name

И выводите любое меню через эту категорию, можете по типу создавать в кссе дополнительное оформление для разных типов.
Вид страницы и код отображения, в зависимости статья это или проект, у вас в любом случае будет отличаться, поэтому и таблицы для статей и проектов у вас тоже будут разными, но привязанными к меню и вы точно будете знать что именно меню означает и куда ведет.

Даже не представляю какие там поля могут быть у проектов, напишу на примере статьи. Имеем таблицы menu, categories.

SELECT menu.id, menu.title, menu.type
FROM menu
INNER JOIN categories ON (categories.id = $выбранная категория для отображения меню)

Comments

[RNB]

и что это даёт? Ещё раз - в сущности Atcicles свой набор полей, в Projects - свой и связь есть с Persons.

[Алексей]

RNB: это дает возможность не плодить сущности без необходимости. В Article у вас не связи с Persons ? Тут важно понять правильная, надежная и масштабируемая ли у вас вообще структура таблиц. Можете дополнить ими вопрос ?

[RNB]

Главная сущность: Категории. У Категории есть Статьи. Теперь появились ещё 2 сущности которые надо показывать в меню. Они никак не статьи. Там будет куча разных полей. Соответственно я их привязал к Категории. Получается что у Категории есть Статьи и Проекты. p.s. В этом-то как раз и вопрос как всё правильно увязать.

[Алексей]

Вы прям жуть как вцепились в эти сущности. Я пишу о том, что не нужно делать категорию главной, это просто связующая таблица, которая определяет вывод того или иного контента. Основным будут являться статьи и проекты, а категория это просто вектор, можно сравнить ее со связующей таблицей. Вы в любом случае будете строить меню по id+title, а он имеет одинаковый формат что у статей, что у проектов и я более чем уверен, что сходства там намного больше, дак зачем же тогда плодить лишние сущности.

[RNB]

Алексей: ну не совсем так. Меню же многослойное: первый уровень - все категории, внутри вложенный список статей и т.д.

[Алексей]

ну тогда нужна ссылка или скрин или хотябы просто код верстки как это должно выглядеть