Привет всем. Сижу - ломаю голову . Как умно, быстро и наименьшими затратами ресурсов решить вот такую задачку:
Есть куча народу, собранных в пирамиду. Т.е. реферальная система. Один привел другого итп..
Есть база типа :
ID Name Refer
Так вот у меня проблема - как красиво и без ососбых затрат каждому пользователю вывести его структуру. Типа такой и тако находится на первом уровне, такой и такой на втором и так далее..
Пока есть только один вариант. Делаю выборку где Refer = ID(текущего пользователя). Имеем первый уровень... Потом берем полученный результат - делаем по каждой найденой записи опять поиск - получаем второй уровень итд... И всё это рекурсисей... Но насколько я представляю - при очень большой ветке - время вычислений будет большим и нагрузка на сервер тоже будет немалая.. вот теперь вопрос - есть ли решенее попроще ?

как красиво и без ососбых затрат каждому пользователю вывести его структуру
кого он привел или всех, кто *пошли* от него?:-)

Все кто пошли от него....

а в PHP нет уже готового елемента, типа TreeView?

Ушел в матрицу.. т.е. читать :)

к.а. я в этот полный чайник

посмотри в Zend Studio: http://www.zend.com/de/products/zend_studio
Типичный случай. Возможно уже сделали такой элемент.
Надо будет только указать источник и несколько атрибутов.

Читать треды лень, напишу, что я использую в этом случае.
Делаю таблицу сущностей безо всяких ссылок, делаю таблицу связей, содержащую ID (сущности), ParentID и количество детей первого уровня. Для построения дерева (или части дерева, где корневым элементом будет сущность с заданным ID) читаю в память таблицу сущностей, читаю в память таблицу связей, в общем, строю два списка. Даже если таблицы огромные, за счёт того, что нет никаких джойнов всё быстро в память засасывается. Далее, допустим, в тривью отображаю всё, загоняю корневым узлом элемент из списка с заданным ID, далее находжу в таблице связей соответствующую запись. Далее в цикле (у нас есть количество детей) к узлу аналогично прицепляю дететей.
С бинарным поиском прикрученным к спискам всё очень быстро происходит без лишных поисков. Можно ещё более оптимизировать и остановиться на чтении непосредственных дететeй, и только когда пользователей откроет узел, для его детей дочитывать необходимую информацию. Для сбора статистики ветка, ессно, должна быть полностью построена.

Только если ты хранишь отдельно всех кто под ним. При вставке - придется апгрейдить кучку вхождений, но это - операция относительно редкая.

А что ты делаешь в случае сбоев по питанию ?
Раз уж инфа должна быть в базе - надо и работать непосредствненно с базой. А производительность - выбор базы, количества процов и памяти... В любом случае делать руками и поддерживать эмулятор ISAM/VSAM - не рентабельно...

Здрасьте, приплыли. Ну, а, что Вы делаете в случае сбоя питания, когда используете дотнетовский датасет? Он, ведь, о ужас, не ориентирован на постоянное соединение! И клиент, получается, не работает всё время непосредственно с базой.

У меня то как раз все понятно - откатываются незаконченные транзакции...
В данной ситуации - те, которые производили замену инфы у потомков...

P.S. Вообще то начинаю подумывать об том, чтобы поменять методику работы - сначала сбрасывать в промежуточные таблицы - там только на запись - операция + инфо, а процессить - уже потом, отдельными потоками. Благо сейчас скорость не критична, а потеря - смертельна...

Зубры опять сцепились :-D

Эээ... покури в сторонке - мы не про Оперу...

Какая неприятность (с)

Чиста как любитель, а процедурку забабахать, которая все сама на сервере вытащит и потом клиенту отдаст в каком-либо виде, не проще?
---
... Если тебя не нашли спасатели - найдyт аpхеологи...

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

Есть, причём разные. И чтобы выбрать правильное надо знать какие операции тебе нужны. Например удаление поддеревьев тебе необходимо? Или только добавление отдельных узлов и быстрая выборка?
ЗЫ отвечу может быть только после выходного.

хоть непосредственно при уходе с узла
------
При этом затраты будут практически такие же, как при работе с базой напрямую. Может даже чуток выше - за счет подъема большего объема данных. Ну если только самостоятельно кешировать всею инфу и бодаться с политикой обновления... Но зачем это надо, если все и так не долго, при правильной организации данных и индексах, делается напрямую с базой?

Ситуация еще банальней. Короче есть программа, которая ведёт учет всей этой линии итп. Из неё можно экспортировать базу данных в том виде, чтьо я писал сверху. Мне нужно просто это дело в инет выставить - чтобы народ мог заходить и просматривать свою ветвь. вот и всё. Т.е. удаление- это всё будет вестись локально с уже существующим софтом.

Эээ... TreeView - было в ActiveX'сах, но это, как сам понимаешь, только под MS...
Если надо везде - Java или мухлевать с HТМЛ'ом...
Честно говоря пользователю там дерево совершенно не нужно - операции пользователя обычно ограничиваются посылкой мессаги или всем рефералам, или кому-то одному. Ни для первого, ни тем более для второго нет нужды показывать дерево.

Мурр ты опять в сторону. Я уже написал что нужно пользователю. Он хочет видеть всю структуру, которая под ним. В любом виде: в виде дерева, в виде списка, разделенным по уровням итп..

Эээ... Объясни заказчику, что есть лимит на размер генерируемого HTML...
Весь объем, загруженный на его систему, ему _не_ нужен и нужен не будет.

Пример с картинками http://vingrad.ru/PHP-FAQ-002203

Ооо - вот это самое простое и вроде как еще и работаещее :)

Суппер - Всем большое спасибо. Всё получилось.
Блин в очередной раз убеждаюсь что германка с её населением - рулит.

> Ооо - вот это самое простое и вроде как еще и работаещее :)
Это решение "в лоб". Оно как пузырьковая сортировка.

Это понятно что в лоб. просто надо было простое... а далее судя по времени - буду делать другое. хотя уже и сейчас на основе этого появились другие мысли.
ЗЫ Блин трудно начинать сначала - последний раз думал лет 6 назад...