Для внутренних проекторв можно сделать join

Вот это конструктивно. 

ладно, будет время, набью тестовыми данными сайт - потестирую…

like работает очень не быстро

длинна строки запроса и ее скорость не совсем симметричные понятия

делать like а потом not in - както не галлантно... и это не сократит, а наоборот увеличит расходы.

Для внутренних проекторв можно сделать join

а. Скорости работы при большом количестве категорий.

б. В принципе, корретной работы движка при больших объемах данных

еще 1 но: а кто права учитывать будет... ведь дело не в длинне строки

Т.к. в запросе все равно будут дополнительные условия, никто не мешает вставить исключающее условие. В среднем исключенных разделов будет многократно меньше подключаемых.

Да и все равно еще надо делать фильтр по дате страницы, ее статусу и прочим параметрам.

Добавлено 44 секунды спустя:

Да пожалуй на счет скорости соглашусь. На счет изменений дерева, так. тут нет большой разницы обновлять 1 поле или 2.

А вот, что меня смущает в текущем механизме работы с категориями, так это вся структура категорий с их свойствами грузиться массив structure, который постоянно находится в памяти. Что при значительном количестве категорий может быть проблемой.

Добавлено 16 часа спустя:

И все же…

Еще помыслил на счет LIKE. Вот пример - инет-магазин количество категорий несколько сотен (700-800), достаточно разветвленное дерево и нам надо провести поиск в определенном разделе сайта включая все его подразделы (их может быть десятки, а может и сотни).

При испотзовании IN (запросы пишу упрощенно просто для понимания) :

SELECT * from cot_pages where page_cat in ('раздел1','подраздел11','подраздел12','подраздел111','подраздел112','подраздел113','подраздел121',…);

Сталкиваемся с тем, что запрос начинает весить очень много, не говоря о том, что каждая дополнительная категория приводит к почти линейному росту времени на выполнение запроса.

У «медленного» на старте LIKE такой зависимости нет, и уже при достаточно небольшом количестве категорий для поиска, LIKE начнет обгонять указанный выше пример.

SELECT * from cot_pages where page_pathcat LIKE '1.%';

Еще есть вариант (хотя не уверен, что он обгонит LIKE):

SELECT * from cot_pages where substr(page_pathcat,1,2) = '1.';

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

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

Очень распространенная задача выбрать все страницы из категории и ее подкатегорий. Сейчас решается вызовом `cot_structure_children` (и.т.п), и последующими запросами вида select * … where page_cat in ('1.1','1.2','1.3','1.4', …). 

Кудап проще было бы просто сделать запрос "… where page_cpath LIKE '1.%'".

Опять же имяя под рукой путь категории этой страницы можно в одну строку получить путь корневой категории или путь родительской: 

$root_path = array_shift( explode( '.', $page_cpath) ); 
$parent_path = substr($page_cpath, 0, strrpos($page_cpath, '.') );