Цитата:
Сообщение от Boodda
В MySQL нет типа полей ARRAY. Вот и начинаются танцы с бубном вокруг того как же селектить.
|
Цитата:
Сообщение от Boodda
у вышестоящего комента запоминаем ID подчинённых комментов в поле с типом ARRAY
|
не вижу _принципиальной_ разницы между этим ARRAY postgresql и строкой с ID, склеенных разделителем. Возможна обработка на языке SQL попроще. Сам же алгоритм основывается на тех же принципах, в твоем случае это: Adjacency List + Materialized Path
Adjacency List - потому что хранишь связь наследник-родитель
Materialized Path - потому что в родителе хранишь всех наследников, что по сути и есть алго MP, хотя в классическом MP можно сразу выбрать ветку со всеми вложенностями одним запросом, тебе же нужна рекурсия, либо во всех родителях хранить всех наследников на каждых уровнях - это ад
У MP проблемы в перемещении узла, но в данной задаче перемещений наверно и не будет. Поэтому имхо тут MP лучшее решение, если говорить об алгоритмах обработки данных. Еще раз упомяну
эту статью, в ней описано подробно 3 алгоритма, лучше чем по другим приведенным ссылкам.
С точки зрения выбора БД, если бы не веб (а может и веб), я бы глянул на
exist-db - native xml database.
XML - это как раз иерархическая структура в текстовом виде, они(exist-db) то уж точно знают как с этим работать - см. язык запросов xquery
Цитата:
|
Сообщение от dady
chesser, большинству здесь нужно "лиж бы работало", а как оно работает пофиг. Я тоже склоняюсь к такому принципу, ибо если делать всё по уму на другое не останется времени) (Если конечно ты не профильный проггер и это твоя работа а не инструмент для помощи в основной работе)
|
ну это понятно, но от процесса поиска того самого идеального решения, я уверен, посетителям топика хуже не станет.
Про "лиж бы работало" - ну это рекурсия и 100500 запросов, а потом все переписывать с нуля, когда траф сайт уложит спать. Почему это произойдет? - потому что комменты, скорее всего, - это одна из наиболее популярных сущностей в БД, имеющая большое количество объектов, которое постоянно будет расти со временем жизни сайта. Комменты могут появляться новые, дополняя сложившееся дерево - значит кешировать их не правильно, либо сложнее обычного.
Прибавление 100500 запросов для загрузки страницы - это плохо, т.к. страницу будут дергать все, кому не лень, включая назойливых ботов. Если вдруг в таблице есть какой-нибудь каунтер (часто любят напихать таких полей), который считает статистику, или обновляет какой-нибудь статус комментов и тд, то это сделает невозможным использование кеша на уровне БД, а он частенько выручает, оттягивая конец сайта на чуть_позже. Коммент - это blob- поле? если да, то при построении join-ов таблицы будут строиться на диске(если не зарулить на tmpfs), вместо памяти. Ну и вообще, комменты - это та часть функционала, которая должна быть вылизана и работать без косяков.
я бы на MP делал + анонимам кешированную статику, зареганным один запрос по MP, возможно, тоже кешировать группы объектов и + механизмы(триггеры) ребилда кеша
а неее, не так, я бы дискус/вконтакте/фейсбук комменты повесил и не парился, щас это модно, гугл/яндекс любит, юзерам тоже норм. хз зачем самому этим заниматься. Меньше кода - меньше багов, нет кода - нет багов
ТС
Линейный вид
