Nested Sets in MySQL (phpDbTree) vs. XML

Фанат

oncle terrible
Команда форума
Snook
В разделе "вопрос-ответ" есть большой материал по деревьям.
нестед сетс - не единственный, и не самый подходящий для тебя вариант.
Читай, выбирай.

А по сути, бредом является вот это твоё заявление:
если по твоему изарвт работа с XML файлами
РАБОТА извратом не является.
А вот использование в качестве БД - изврат.
причем изврат настолько общеизвестный, как 2х2=4, что у всех и вызывает изумление, что перед тобой такой вопрос до сих пор стоит
 

Wicked

Новичок
Понятно что такое tree_id.
Меня беспокоил не размер таблицы, а быстродействие. В случае если это будет одно дерево на все сущности, то при добавлении элемента в это дерево надо обновлять большую часть веток, а есл поточнее то изменить cleft и crigрt у всех элементов которые правее парента вставки. Т.е. обвновляются не только комментарии для данной сущность в всё (условно всё) дерево.
Если делать с tree_id то при добавлении коментария на сущность никакие другие сущности не затрагиваются. И получается не 1 дерево с 1000 ветвей а например 100 деревьев по 10 ветвей.
Соответственно получаем быстродействие дерева с 10 ветвями а не с 1000.
Первое вменяемое сообщение.

Давай ты пока что сделаешь лес деревьев, набьешь туда 40000 тем и 400000 комментариев и замеришь последующую скорость
просмотра темы, добавления новой темы, добавления комментария, и т.д. Я почти уверен, что если ты все сделаешь без ляпов (типа забытых индексов), то по быстродействию у тебя нареканий не будет.
 

Snook

Новичок
:) да с лесом вариант получше конечно... Щас класс делаю чтобы понимал лес а не одно дерево.
+ читаю большой материал по деревьям.
 

Фанат

oncle terrible
Команда форума
блин, не нужны никакие классы.
Для комментариев подойдет вообще любой вариант. простоая работа с бд, безо всяких классов.
 

Snook

Новичок
Ну проще же вызвать $tree->insert(....); чем писать запросы каждый раз... + заюзать надо не в одном же месте
 

Фанат

oncle terrible
Команда форума
ни хрена не удобнее.

что значит - "каждый раз"?! что значит "не в одном же месте"???
вставка в базу делается ОДИН раз в ОДНОМ месте - в коде обработки поста.

язык SQL - это УЖЕ прекрасная абстракция работы с данными.
и городить лишнюю обертку нафиг не нужно
 

Wicked

Новичок
Фанат
Имхо ты перегибаешь палку.
Есть готорвый класс, который надо немного подправить для работы в условиях леса. Вместо этого ты предлагаешь выбросить его целиком на помойку, и написать все инлайн. И не забывай, что nested sets накладывают некоторые ограничения на поступающие в базу данные, разруливание чего как раз инкапсулировано в этом классе.
 

Snook

Новичок
"каждый раз" имелось ввиду при вставке, извлечени + в других модулях, "не в одном же месте" - не в одном же проекте... :)
 

Vallar_ultra

Любитель выпить :)
nested sets - это точно какая-то религия.... Объясните мне: почему именно такой вид хранения? В данном случае он ведь не оптимален.
 

Фанат

oncle terrible
Команда форума
Я предлагаю НЕ пользоваться nested sets, и соответственно, НЕ спотыкаться об ограничения, накладываемые.
в данном случае, как мне кажется, прекрасно подойдет технология, которая называется, кажется, materialized path
её использование отличается от работы с обычным одноранговым списком в БД ровно одним дополнительным запросом при вставке. ВСЁ.
Вывод - обычный.
Нафига тут какие-то классы?
тебе нужен специальный класс для получения комментов из бд? класс для получения записей вообще уже не подойдёт?
 

Wicked

Новичок
Vallar_ultra
ибо удобные и быстрые выборки за счет обычно незначительных затрат при изменении данных. Селко почитай что ли :)
 

Фанат

oncle terrible
Команда форума
Snook
У тебя с головой все в порядке?
какое ещё $tree->insert(....); при ИЗВЛЕЧЕНИИ?
что именно ты собрался делать в других модулях?
получать комменты? ради бога - заверни в класс или в функцию.
но это будет класс для получения комментов из бд, а не КЛАСС РАБОТЫ С ДЕРЕВЬЯМИ
 

Vallar_ultra

Любитель выпить :)
Wicked
ИМХО. в данном случае и обычные деревья вполне прокатят.
SELEC * FROM comments WHERE terget = 1 ORDER BY pid ASC, id ASC
полученный результат в 1-м проходе распихиваем в нужный вид/стр-ру и наслаждаемся жизнью. Мы же не можем пид менять в комментах - т.ч. родитель всегда будет в результате выборки выше чем потомок.
 

Фанат

oncle terrible
Команда форума
Vallar_ultra
парсинг в пхп не пойдет. постраничный вывод.
и не спорь.
 

Wicked

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

Vallar_ultra

Любитель выпить :)
Wicked
Да я уже согласился что ступил. для того чтоб это бегало, есть один финт ушами - но в рамках конкретной задачи он нафик не нужен. Вобщем про ClassicTree я погорячился.... хотя nested sets тоже не панацея =)
 

Фанат

oncle terrible
Команда форума
Wicked
куда ты собрался поддеревья переносить в комментах?
 

Snook

Новичок
Чё вы все тут кипятитесь.
Всё у меня в порядке с головой.

$tree->insert(....); - это, а именно название метода insert было приведено как пример, это во-первых.

Во-вторых ты типа сопоставил слова insert и ИЗВЛЕЧЕНИИ и тебе это показалось странным? Т.е. ты по названию знаешь что там у меня может делаться? Может у меня там инсерт дерева комментариев на страницу. Непонимаю чё тут кипятиться.

"а не КЛАСС РАБОТЫ С ДЕРЕВЬЯМИ " я где то такое писал? или тебе самому приснилось. В других модулях я собрался использовать такую же структуру комментариев и не только комментариев. Да я собрался получать комменты из класса и работать с ними.

Вскипятились чё то на ровном месте... всего лишь надо мне добавить поддержку леса в класс CDBTree. Кстаи это же и написано в факе на этом же сайте:
"идеальная библиотека должна позволять хранить в одной таблице не одно дерево, а несколько. Деревья различаются между собой идентификатором. Поскольку для этого требуется введение дополнительного поля в таблицу, то должна быть отдельная настройка, задающая наличие этой возможности.
Например, древовидный форум. Каждая тема – отдельное дерево в таблице. Тогда добавление нового сообщения в тему не затронит другие темы."

Что теперь не в порядке с головой у кого.
 
Сверху