Деревья для форума

[pilot911]

Деревья для форума

Есть маленький вопросик.

Использую обычную схему для веток форума - ID <- PID

Но сейчас возникла необходимость при добавлении сообщения в какой-то форум увеличивать счетчик сообщений у всех родительских форумах.

Как лучше это сделать? Вообще, какие деревья используются в форумах ?

 

[zerkms]

если начинает не хватать adjacency list - начинай смотреть в сторону materialized path

 

[AmdY]

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

 

[pilot911]

вложенность неограниченная

хотя судя по searchengines.ru и другим форумам - уровень вложенности максимум 5, поэтому твое, AmdY, предложение работает хорошо - но для каждой новой мессаги и апдейта родителей придется строить join

самое простое, судя по мыслям, взять сразу всех родителей и просуммировать у каждого поле total_messages+1 ... materialized path здесь в тему, однако при перемещении топика в другой раздел придется пересчитывать поля total_messages у новых и старых родителей ... да еще и менять materialized path у всех вложенных топиков...

но что-то нестед кажется еще сложнее для этой темы, поэтому пока выберу materialized path

 

[zerkms]

materialized path здесь в тему, однако при перемещении топика в другой раздел придется пересчитывать поля total_messages у новых и старых родителей ... да еще и менять materialized path у всех вложенных топиков...

придётся пересчитывать при любой технике хранения деревьев.

 

[SiMM]

AmdY> если вложенность ограниченная, то можно юзать много табличный апдейт с join
А какие ограничения на количество join'ов у MySQL'я?

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

 

[AmdY]

SiMM
некогда было около 32, но сейчас вроде значительно больше. но меня интересовал вопрос с эстетической точки зрения, а то ведь на практике вложеность обычно 2-3 уровня, а пытаются придумывать алгоритмы как для бесконечной вложенностью с миллионом эллементов

 

[Wicked]

Но сейчас возникла необходимость при добавлении сообщения в какой-то форум увеличивать счетчик сообщений у всех родительских форумах.

это как-то противоречит идее adjacency lists?

 

[john.brown]

Автор оригинала: pilot911
но что-то нестед кажется еще сложнее для этой темы

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

 

[pilot911]

впечатлился этой статьей


часть 1


часть 2


Классы

 

[Wicked]

а я не впечатлился

потому что, например, вот так:

SELECT * FROM my_tree
WHERE '$path' RLIKE CONCAT('^', path, '%')
ORDER BY path;

делать НЕ надо. Надо делать where path in ('01', '0102', '010202').

 

[john.brown]

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

 

[pilot911]

ну по идее, всегда есть pid родителя - по нему всегда же можно восстановить полную картину

 

[john.brown]

Да, невыполнимых задач нет Но т.к. недавно реализовывал оба варианта хранения дерева - начал как раз с материальных путей, а закончил нестед сетами, то лично мне первый вариант в реализации показался реально гемморойнее - после того, как надоело боротся с глюками и неучтенными случаями, переписал все на нестед. И короче оказалось, и проще... Хотя по началу тоже сооблазнился materialized path...