Zloxa
То есть, получается, что вариант с отдельной таблицей вполне "живучий"...
Объём... 100 000 сотрудников и 300 уровень вложенности... получается...
5 000 050 000 записей при абсолютном условии, если выстраивать линейное дерево, т.е. элемент под элементом.. (арифм. прогрессия)

По поводу сотрудников я привёл пример, чтобы было понятно всем, а не только мне   
Я вначале написал, что это вымышленно...
Фирма да, не нанимает по 3 сотрудника в день   
В моём случае, 3 сотрудника в день даже маловато - будет около 10...

Но... есть и такие, кто действительно нанимает...  
Например, промоутеры - их по 10-20 в день нанимают   Недельку поработают, и уходят  
Но это тоже вымышленный пример   
Главное - смысл, а не кто и что ;)

MP предков я храню в поле типа TEXT.
Про ограничения - не думал, что там они есть...
По поводу длины пути... 300 {уровень} x (5 {длина id} + 1 {разделитель}) = 300 х 6 = 1800 = около 2000 символов, что не так уж и много   
Хм... пожалуй, надо сменить тип с TEXT на VARCHAR   

Сканировать всех не надо - думаю, что всё остановится на выборке 500 дочерних пользователей, чтобы проверить количество заявок и изменений в них.
Если будет более 500, то оно будет обрезаться по типу breaker'а, как я писал выше.

Это сообщение отредактировал(а) fridkaratel - 18.6.2012, 10:17

и по нему лайкаешь? :facepalm


Опять же, здесь разные оценивают по разному. 
По мне так - это уже достаточно много, чтобы не хранить в строке.
Я бы, лично, использовал строку для хранения MP лишь в случае, если глубина лишь в редких могла бы превышать 5. Край - 10.

Ну... да...   
Расскажи, пожалуйста, вкратце, чем это плохо...
А то у меня ещё и поиск товаров по описаниям сделан через LIKE %слово%...   


Эх, то есть всё же NS?

Это сообщение отредактировал(а) fridkaratel - 18.6.2012, 10:29

Еще раз повторюсь. Тут - тебе решать.
Тем более, что предметная область столь специфична, что понятна только тебе ))

если тебя устраивает то, что можно получить от MP, я бы склонился к MP с 5млн записей.
Но это будет плохо работать для узлов на низком уровне влженности - слишком низкая селективность для индексного доступа.

Но вобще, если бы мы говорили о штатном расписании, я полагаю имело бы смысл разделить сущности "штатное расписание" суть древообразное и "сотрудники", суть линейное, состоящее в отношении со штатным расписанием. А штатное расписание- столь редко меняющаяся сущность, что NS туда так и просится.

Это сообщение отредактировал(а) Zloxa - 18.6.2012, 10:36

[quote]если тебя устраивает то, что можно получить от MP, я бы склонился к MP с 5млн записей.[/qoute]
Немного не понял... то есть если меньше 5 млн., то MP сгодится?


То есть, если дочерний элемент находится на 200-м уровне, то будут проблемы со скоростью, так?


Zloxa, опиши, пожалуйста, подробней... Что-то улавливаю, но не до конца...

Нет, на 200м как раз таки все будет хорошо. Плохо будет на первом и втором.

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


А смысл? У тебя же не штатное расписание.  То - так, мысли в слух были.

Но вобще суть сводится к тому, что если у тебя нанимается региональный администратор, вовсе не обязательно для него заводить обособленный лист дерева. Дерево, вообще при найме-увольнении сотрудников, меняться не должно бы. В дереве указывается роль и подчинение. Один человек, физически, может играть несколько ролей. Васисуалий Лоханкин может одновременно быть и программистом в неком региональном отделении и уборщиком в центральном офисе. Одно другому не мешает. А ввод новых должностей и переподчинение производятся куда реже нежели найм/увольнение сотрудников. В худшем случае - пару раз в год.


NS, емнип, позволяет производить эффективно несколько более широкий спектр операций по выборке из дерева, нежели MP.  Если тебе нужно только искать потомков вглубь, MP - сгодится.

Это сообщение отредактировал(а) Zloxa - 18.6.2012, 11:56