Програмёр,

чем дальше, тем интересней... и зачем тебе нестид сетс тогда.

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

а инноДБ для твоей базы, когда в които веки надо будет удалить ветку, сделает это автоматически при соответсвующем каскадном действии..

Програмёрalex564657498765453Програмёр,

чем дальше, тем интересней... и зачем тебе нестид сетс тогда.

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

а инноДБ для твоей базы, когда в които веки надо будет удалить ветку, сделает это автоматически при соответсвующем каскадном действии..

Особенно интересно это звучит в момент, когда надо скопировать ветку и вставить в другом месте. Просто недавно был случай, когда организация открыла ещё один техцентр и было дано задание "всё, что есть в первом техцентре надо в точности перенести во второй техцентр, только поменять там .... " (разумеется от SEO'шника по шапке получили и сразу поменяли и тексты дублей). Однако с трёхуровневой структурой меню я долбался около часа, в то время как на nested sets такое копирование заняло бы от силы 10 минут (вернее даже меньше).

ситуации разные бывают :) Завязываться на нестандартных возможностях движка innoDB (имеется ввиду на тех, которых нету в других движках, типа как каскадные действия) я не хочу... Авось клиент скажет что не может врубить этот движок у себя на серваке? или например что-то пойдёт не так и в какой-то момент надо будет поменять движок (мало ли... всё надо продумать)... Или вообще база поменяется (например с mysql на ту же mssql надо будет перевести)? И вместо беглого взгляда на код и правки 10 строчек всё обойдётся в конкретные костыли и изменение структуры всего :)

Система делается глобальная и по возможности универсальная.

P.S. по поводу " как я понимаю тебе такие задачи не светят, тебе надо будет выбирать только непосредственых потомков". Да элементарно.... Вот например на одном из планируемых сайтов в ТЗ прописано наличие страницы "карта сайта" :) В моём случае моё дерево и есть в прямом виде карта сайта (конечно подразумевается в таблице наличие пункта "показать в карте сайта"). И какая польза от такой карты, если пользователю придётся её разворачивать уровень за уровнем (при этом другие ветки будут скрыты, то есть он может не найти то, что ему надо). Ему нужна полноценная развёрнутая карта. А как это сделать без рекурсии, если хранить данные не в формате nested sets?

Или ещё... Для другого сайта требуется по дизайну писать общее количество наименований товаров в категории... Как мне это сделать без рекурсии?

Так что нет, этот формат как-раз для моих нужд очень удобен.

про "нестандартные" возможности иннодб тебе написали.

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

а нащёт варианта, что части твоей базы в другие копируються... ну сдесь да, нестид сетс тебя спасёт.(разово я бы и без нестид сетс делал

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

Модератор: Тема перенесена из форума "PHP, Perl, Python".