Как делать «многоуровневые» страницы, как в интернет магазинах?
Не знаю как это называется. Но вот, например: Заходишь ты в интернет магазин, а там категория, выбираешь, там еще подкатегория, выбираешь, там еще. Получается для того что бы дойти до нужно товара, нужно пройти несколько уровней страниц.
Хочу сделать примерно такой же сайт. Так, для практики. Но не знаю как все это хранить.
- Может для каждой категории и подкатегориям и ... N-подкатегории создать отдельные страницы?
Может получится очень много страниц. А что если категории придется часто добавлять\удалять?
Но, ведь, так дело не пойдет.
А как вообще хранят такие сайты?
Создавать для каждой под категории отдельные таблицы в БД?
А как ссылать друг к другу?
Еще слышал (но не знаю как их делают) про хлебные крошки, которые запоминаю путь.
В примере с интернет магазином: А что если на один и тот же товар можно прийти из разных категорий.
Ну, например если товар одновременно одежда и сувенир (это я так, к примеру).
Вообщем, фантазировать я могу долго. Помогите пожалуйста разобраться с этой темой. Очень хочу понять как все это делается.
Представь систему как кучу массивов с данными.
Страница - массив с данными
Товар - массив с данными
Модель - массив с данными
Некоторые поля массива могут быть множественные, например страна производства для модели, их хранят как получится - кто-то в строке текстовой через разделитель, кто-то в json пхает, кто как.
Таким образом для сайта тебе нужно иметь кучу страниц (массивов)
Каждый из этих массивов может одновременно быть моделью и товаром, или моделью, или товаром, или вообще просто страницей.
То есть на каждый такой массив будет несколько связей и относительно каждой связи будут собственные данные.
При выводе страницы твоя задача собрать все что ты знаешь об этой странице - данные товара, данные модели, данные самой страницы.
Потом сложить повторяющиеся свойства по уровню вложенности, то есть товар имеет наивысший приоритет, если у модели и товара свойство имеет одно и тоже название - свойство товара является более важным и потому свойство модели удаляется.
В конце у тебя получится массив страницы со свойствами. Его выводи на верстку.
Подход вида "отдельная таблица для категорий", "отдельная таблица для товаров" и тд очень неудобен по обслуживанию, и имеет смысл только для очень толстых проектов - где миллионы записей и хранение вида:
`таблица элементов`,
`таблица типов элементов`,
`таблица имен параметров`,
`таблица значений параметров элементов`,
`таблица вложенности элементов по типам`,
`таблица принадлежности всех типов главному типу`,
уже вызывает медленную работу. Размер проекта действительно должен быть огромным.
Правильный запрос при структуре указанной выше работает прекрасно для магазинов даже 100 тысяч товаров, 5000 категорий и тд, разделение страниц и тд
Если у тебя пара миллионов товаров - тогда нужно начинать бить, и твои свойства уже будут каждое в своей таблице - отдельно категории, отдельно товары, отдельно страницы и тд. и свойства этих элементов уже будут в самих таблицах, а не в одном месте.
Я хочу сказать, что если сайт состоит из страниц - то основной тип - это страница, а все остальное - привязанные к ней массивы, которые вкладываются друг в друга как нужно.
Сами же страницы имеют уникальный ключ - ее адрес в интернете, но для удобства связывания используется ID ее в системе.
Таким образом страница может быть типом элемента или отдельной таблицей, где объявлена страница (id) и её адрес, а также стандартные свойства description, keywords, search_content и подобные (тут нужно смотреть от уровня бюджета) - чем больше тем лучше, но тем дольше и дороже.
В битриксе например решили не делать элемент-страниц - они просто разложили их по папкам, как будто это файловая система - если главная страница лежит в папке /holodilniki/index.php - то она так и будет доступна, а в ее коде будет сделан запрос вида "взять определенное число холодильников и вывести их с постраничной навигацией".
Если у тебя не будет такой структуры вложенности - ты можешь сразу хранить адреса и ид страниц в базе, и тогда на сайт заходишь там index.php, а он все равно работает.
По сути твое хранение данных разбивается на несколько источников - это база, это кеши (временное хранилище уже полученных однажды данных на короткое время), это php файлы и их конфиги, это другие источники (такие как поставщики и предварительно подготовленные таблицы с разобранными вручную данными) и вся работа программиста состоит в том, чтобы научится быстро соединять эти источники и получать из них данные.
