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


естественно не следует употреблять дерево в больших массивах - можно обойтись только верхними узлами в таблице с возможностью детализации,
но к примеру, есть конструкторский справочник, в котором одинаковые подсборки могут быть привязаны к разным узлам
как этот вопрос решает дерево - оно привязывает к первому узлу и больше эту подсборку не видит,
реальная ситуация - около 15 тысяч наименований, кончая гайками и припоем, количество связей достигает около 100 тысяч, генерировать запрос так чтобы тянулись все 100 тысяч дублированных записей - неправильно, а из 15 тысяч будет построено неправильное дерево, значит это неправильное дерево

progeishaреальная ситуация - около 15 тысяч наименований, кончая гайками и припоем, количество связей достигает около 100 тысяч

имею в виду конструкторский справочник

Валентин К
Поставьте
FetchAllOnOpen в true и считайте справочник, или конструкцию, в которой будет 2 поля ключ и ссылка на родительский ключ, вот собственно и фся проблема...

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

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

by the wayДля того, чтобы это узнать, надо проверить существование одного единственного подчиненного узла - можно сделать подзапросом, или, что удобнее для разработчика, с помрощью UDF

так если в дереве нет свойства читающего наличие узлов, то как это отобразится на экране?

Валентин КВсе равно не понял необходимости задваивать записи, это понятно, что left join перемножит 1-й датасет на 2-й, но можно лишние срезать distinct, по-моему это из-за того, что хранение записей не до конца продумано, если есть ссылки на всех родителей в отдельных строках, не проще ли прописать список родителей через запятую....

наверное Вы не представляете конструкторский справочник, там вложенность очень глубокая, и писать всех родителей через запятую...
конечно left join перемножит 1-й датасет на 2-й, и подчиненный узел(2 уровень) будет дублироваться, а дочерние(3 ровень) к подчиненному(2 уровень) не будут дублироваться, вот они то и потеряются в мемтабл,

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

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

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

Dogen Валентин К progeishaдочерняя запись дублировалась столько раз, сколько у нее родителейэто уже не дерево, или я чего-то недопонял?

ну нос ивана петровича не тоже самое что нос ивана никифоровича, так что? создавать в базе две записи "нос" чтобы было настоящее дерево?

DogenНе называть это деревом. Вот когда будете отрисовывать в GUI, тогда придется нарисовать дерево.

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

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

Валентин КДумаю, что вопрос прояснил. Не виже причин для спора.

я не спорю, а пытаюсь выяснить, вот например

Валентин КВаша ситуция по дереву рулится 2-мя стандартными способами
1) Стянуть только корневых родителей, и поставить к ним плюсики или к каждому подтянуть по 1 потомку любого одного вида, который попадется для индикатора плюсиков вложенности. По мере того, как юзверь скроллится по дереву и двигается вглубь докачивать ветки. Наиболее быстрый способ.


второй вариант меня тоже не интересует, как нежизнеспособный, а вот с первым... то есть, такой механизм, который вы описываете в первом варианте, есть в memtable? тогда я извиняюсь за напор и перед всеми говорю - Валентин прав, а я дура, недосмотрела опубликованные свойства... может у меня была ранняя версия, но вообщем все равно облажалась

а если же это некое пошаговое руководство к действию, то я и сама это знаю, и в моем дереве примерно так и работает, с докачкой, так что тоже нет причин для спора

вопрос стоял - есть это ehlib или нет