Как лучше организовать структуру объекта категории, у которого есть большой текст?
Прошу не пинать сильно за нубский вопрос. Вопрос не относится конкретно к Symfony, но работаю именно с нею и Doctrine.
Мне нужно сделать категории на сайте - по факту это меню сайта состоящее из 50-60 пунктов. У категории имеется текст - в среднем размер текста около 6кб. Меню присутствует на всех страницах (ну, как обычно на сайтах), но ведь текст выводится только текущей категории, а не всех сразу. Получается, что остальные категории будут просто расходовать ресурсы сервера, а на виртуальном хостинге они не безграничны.
Я не опытный программист, поэтому прошу совета. Как лучше организовать объект категории:
- оставить в категории просто поле с текстом?
- или же вынести текст в отдельный объект и внедрять его в категорию?
Возможно из-за использования доктрины в Symfony расход ресурсов будет большим, ежели на нативном PDO, и все таки лучше использовать вложенный объект с текстом? Спрашиваю об этом т.к. у Symfony есть возможность использовать "ленивую загрузку". И если я правильно понимаю, то при ее использовании, и категориях с внедряемыми объектами, загружены будут не все тексты 60ти категорий, а только та, к которой будет обращение, что сократит расход ресурсов.
Вообще, подскажите, как это обычно делают? Дело в том, что хочу сделать еще и теги, которые однозначно будут внедряемыми объектами в категории (описанные выше) и другие объекты (например, статьи, картинки). Тегам тоже нужно бы добавить текст для SEO оптимизации, который так же будет показываться на страничке только если активен (выбран) заданный тег. И получается что у категории будет и свой текст, и тексты всех тегов, которые назначены категории. В этом случае нужно и у тегов текст внедрять отдельным объектом?
Меню присутствует на всех страницах (ну, как обычно на сайтах), но ведь текст выводится только текущей категории, а не всех сразу.
Что вам мешает указать только нужные поля (название, родитель) для меню? А дополнительные атрибуты конкретной категории выводить вторым запросом...
Вообще меню не должно на контент влиять ведь -- это ведь на всех страницах :)
А контент конкретной страницы (в категории это контент категории и товары в ней) живет уже в своем методе конкретного контроллера :)
Что вам мешает указать только нужные поля (название, родитель) для меню? А дополнительные атрибуты конкретной категории выводить вторым запросом...
Максим Федоров, гениально и просто! Я не подумал о том, что можно не все поля забирать из БД для генерации меню, а только самые необходимые, вроде id и title - их будет достаточно ведь для меню. :)
Нет необходимости выноса ни текста ни остальной информации (превью, метаданных и прочего). вся информация касающаяся одной категории должна находиться вместе, в одной строке бд. если бы эти данные относились не к конкретной категории, а к группе или какой либо другой, тогда можно было обдумать структурирование, но если данные уникальные, то разбивать их не стоит. Что касается запросов, то функционально нужно разносить - просто вывод категорий, возможно с превью; вывод самой категории на отдельной странице с описанием и другим контентом;
Разумеется это разные запросы к бд и не полный список, основные. Напомню еще что категории сами по себе имеют древовидное представление (обычно так). Поэтому про родителей не забываем и реализацию лучше где нить подсмотреть. как то так.
Что касается запросов, то функционально нужно разносить - просто вывод категорий, возможно с превью; вывод самой категории на отдельной странице с описанием и другим контентом;
Т.е. для вывода списка категорий делать запрос типа "SELECT id, title", т.е. без загрузки текстов, а для вывода страницы самой категории запрос вида "SELECT * ... ", т.е. все поля?
А в доктрине есть такая возможность, не подскажете?
Средний
