Ok, попробуем, может действительно лучше будет.
Уважаемые пользователи! По результатам обращений в техподдержку на бирже создан раздел "Вопросы и ответы".
Проблему решаем, вчера не было возможности ответить. Извините за неудобства.
Червонцевые заказы приняты к исполнению ))) потому и исчезли
обновлять левелы трудоемко для базы, да и по сути излишняя это инфа, хотя можеть быть это то, где избыточность полезна... в общем на примерах смотреть нужно, что то мне не нравится эта идея...
не за что )) давай те лучше в понедельник, завтра выходные, отдыхать от компа надо... надо придумать еще что нибудь интересное.
базы можно здесь посмотреть http://www.maxmind.com/app/csv
кэширование не заменяет оптимальный алгоритм построения деревьев, это просто некая следующая ступень оптимизации.
1. Категории обновляются, то есть кэшируем мы на несколько минут. Кэшируется и весь результат, но дерево категорий используется и в некэширующихся местах. То есть имеем частичное кэширование.
2. 1 запрос по праймари не виснет, виснет очередь из нескольких тысяч таких запросов в секунду. К тому же паралельно много и других, довольно тяжелых запросов. Одно дерево нафиг никому не нужно по большому счету, нужно в сочетании.
3. Эффективный поиск пока в разработке, сейчас обычный полнотекстовый поиск по базе с указанием id категорий.
4. Рекурсия - не плохо, это математика и это хорошо. Только с умом.
5. Хранить левел - это удобно выводить, но не удобно обновлять, если что, кучи апдейтов и насилование мозга, не дай бог цифирку упустить. Было, проходили уже.
6. Путь к узлу не решит все задачи.
В общем все эти задачи у меня решаются один запросом, который я написал выше. На практике работает в целом отлично.
да, штука тяжелая, но работает. У меня есть мысли, что по уму то надо бы у категории хранить инфу о подкатегориях, то есть использовать некую таблицу связок. Возможно это будет быстрее, чем IN (500 категорий), не проверял, хотя тут по индексам нормально.
Да, забыл что еще необходимо: в любой момент каждая категория должна знать своих потомков. Всех.
А про доступ к каждой категории. Предположим есть список статей с категоризацией. Если мы уже построили дерево для поиска в категориях, неужели мы будет опять выбирать названия категории, к которой относится каждая статья?
1. Задача не из учебника, а реальная. Проект http://www.tkat.ru
2. Связанные списки, я не математик, поэтому понимаю, что в этом случае каждая категория знает соседа и тд. Без доп выборок. Ну это оффтоп в нашем вопросе.
3. Селект - это я к тому, зачем на странице полное дерево. Например, искать в категории. А то скажут, что не нужно.
4. По большому счету и по моему мнению уровень вложенности не должен играть какую либо важную роль.
5. То что Вы описали очень реально для небольшой нагрузки, а у нас она за 100К в сутки + ботов еще почти столько же. Столкнулся с тем, что в списке процессов все эти рекурсивные запросы висели десятками минут, и шли они нарастающим итогом. Серваку было очень нехорошо, да и хостер волновался.
6. Практика показала, что доставание категорий запросом select * from category и последующий разбор пхпой, с возможным кэшированием на диске/в памяти построенного дерева, эффективней рекурсивных запросов примерно в 1000 раз - только по замеру времени, а про зависшие эти запросы в процессах под реальной нагрузкой я уже забыл. 🚬
