Подсчет колич-ва объектов — пересечение 2 деревьев

segoddnja, это ничего не меняет. Деревья уже работают и очень хорошо.
Проблема в другом. Не вижу смысла переделать, так как это никак не облегчит мне задачу.

Цитата ("WebDesignStudio"):

и что это даст? Ведь проблема в самой логике а не в используемом механизме.

1. Вы получите скорость на порядок больше, чем даст sql
2. чуть "усложняется" запись (точнее она другая)
3. в редисе есть функция нахождения пересечения множеств.

Цитата ("WebDesignStudio"):

допустим заходит на главной пользователь А. Он выбрал Киевскую область. Ему надо показать сколько всего объявлений в Киевской области И в городах этой области(тут на практике вложенность городов=2).
Но надо не общее количество, а для каждой категории отдельно.

ну? тупо массив данных.. хоть сериализованный в мемкэш, или выборка из mongo, или выборка "ветки"- множества из redis
{Московская область:1232424
;
Питер:3535;
Киевская область:2324

}

т.е. при записи 1 объявления надо тупо сделать 2 записи: в город и область (+категорию, в примере их нет, но я умаю, что и так понятно)
итого имея 3 мгновенных зиписи получаем супермгновенныю выдачу результата без обращения к sql

ArtPro, а если категория последнего уровня? Надо добавить +1 для всех ее родителей.
А что если делать изменение категории? Или хуже, менять местами категорию. Это наверное будет не часто, но предусмотреть нужно.

Цитата ("WebDesignStudio"):

ArtPro, а если категория последнего уровня? Надо добавить +1 для всех ее родителей.
А что если делать изменение категории? Или хуже, менять местами категорию. Это наверное будет не часто, но предусмотреть нужно.

если мы говорим про нормальную работу при нагрузке, то лучше умно записать, чем тупо считывать
у нас чем больше уровней, тем больше "добавлений" при инкременте потомка. если N вложений, то N плюсов. для мемкэша - это N операторов inc(keyname)
причем если у нам будет так, что число объяв в московской области - это ключ "moskowreg", то ключ для москвы = "moskowreg:moskow" .... раздел бытовая техника? - "moskowreg:moskow:hometech" подраздел Холодильники? - "moskowreg:moskow:hometech:ice"

и так, что бы нам добавить объяву в moskowreg:moskow:hometech:ice - надо сделать:
inc('moskowreg:moskow:hometech:ice';
inc('moskowreg:moskow:hometech';
inc('moskowreg:moskow';
inc('moskowreg';

можно explode использовать и в цикле...
зато насколько проще делать выборки... насколько просто создать раздел/подраздел/город и т.п....

А что если просто тупо забить в таблицу все пары город-категория, добавить к ним поле количества объявлений и менять его при добавлении/удалении нового? В итоге выйдет 500 000 строк, но их набор практически не будет меняться. В таблицу добавить индекс по двум полям, самые популярные или последние пары кешировать. Выбирать общий список можно будет одним запросом, ведь мы будем знать все нужные пары.

Цитата ("yefrem"):

А что если просто тупо забить в таблицу все пары город-категория, добавить к ним поле количества объявлений и менять его при добавлении/удалении нового? В итоге выйдет 500 000 строк, но их набор практически не будет меняться. В таблицу добавить индекс по двум полям, самые популярные или последние пары кешировать. Выбирать общий список можно будет одним запросом, ведь мы будем знать все нужные пары.

подумал и об этом варианте. Вы ошибаетесь. Тут древовидная структура. Менять придется по несколько записей на каждое добавление. Редактирование вообще проблематично будет. И чтение из такую таблице не так уж и быстро. Лучше на файлах как я писал.

Цитата ("yefrem"):

В итоге выйдет 500 000 строк,

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

Цитата ("WebDesignStudio"):

подумал и об этом варианте. Вы ошибаетесь. Тут древовидная структура. Менять придется по несколько записей на каждое добавление. Редактирование вообще проблематично будет. И чтение из такую таблице не так уж и быстро. Лучше на файлах как я писал.

Как правильно заметил ArtPro, лучше пусть добавление будет медленным и неудобным, чем выборка. К тому же, не таким и неудобным оно будет. При уровне вложенности 2 это будет на одно изменение больше при сохранении и удалении. В любом случае, лучше дополнительных 1-2 запроса при сохранении, чем всякие COUNT(*) при выборке. Плюс кеш, как написали выше.
И да, я не верю, что с файлами быстрее, даже если без кеширования.

Цитата ("yefrem"):

И да, я не верю, что с файлами быстрее, даже если без кеширования.

файлы?? диск не лопнет?? вы статистику по числу операций посмотрите у дисков + отдача статики+ база+ дофига всего
а тот же мемкэш или редис по 100 тыс записей отдавать в секунду будет из памяти

Почему выбрана реализация деревьев не в виде nested sets?
ссылка

Raskumandrin
Именно.

1-е дерево - категории
2-е дерево - география
и таблица пересечения:
поля:
PK если надо
id узла категории
id узла географии
кол-во

при добавлении объявления меняется только одна строка в третьей таблице

выборка максимум 3 запроса
изменение деревьев происходит в соотв. таблицах и на множествах выполняется элементарно.

PS заявку оставил