озадачился, как оптимальнее всего сделать вложенные комментарии... например как на скриншоте: т.е. камент от alienator (17:57) является ответом на камент от 0Lexx0 (17:50), но ниже стоит камент от Abductio (17:52) у кого какие мысли? единым запросом из БД в таком порядке как-то непонятно как можно взять... а пересортировывать каждый раз чредсвами ПХП в памяти, тоже расточительно %) особенно если встанет задача выдать большое кол-во каментов на одной странице...
Например хранить именованный путь. Например - 1 1.23 1.23.15 1.23.16 1.23.17 - где цифры - это ID записи Так и уровень несложно считать
хорошо, допустим пользователь отвечает на камент у коготого позиция в вашем примере равна 12, тогда какую позицию надо присвоить новому каменту?
Тоже самое когда то реализовал в своем проекте с parent_id, остальные сообщения сами по себе сортируются по дате/ид. Если parent_id == 0 тогда это просто новый независимый комментарий. Но самое интересное - что делать с дизайном сайта когда на каждый ответ идет еще ответ, и выстраивается дерево на 7+ ступеней
а в моем способе - чтобы узнать уровень вложенности - просто считаешь сколько точек =) Все легко и просто)
ну все просто же. получаем с=COUNT() как-то так tree LIKE '12%' тогда tree='12'.(с+1) кстати, по-правильному, нужно добавить разделитель между цифрами. точку например. tommyangelo а если каментов лимончик, а если два...
иду на допущение конечно, но почему то мне кажется, что уровень вложенности не будет превышать 70 Лимончик - это 7 символов, потому мы возьмем случай с 9 символами - как раз до миллиарда 1 коммент не дотянем. 70*10 = 700 10 - это с точками. 700 символов - фигня для MySql. А уровень можно проще считать - дописывать в путь нолики, до 9 символов. Т.е. 000000012.000005689.00012583 и.т.д. Тогда уровень будет тупо length(path)/10
и помножить все это на 100000000 комментов и потом, есть ещё и разница, делать индекс по varchar(70) или по varchar(700) правильнее так 1.2.1 займет место после 1.2
ну в моем способе точки считает (т.е. делает отступы слева) css, но возможную теоретическую проблему это не решает
Mr.M.I.T. один фиг без бенчмарков обсуждаем - недоказуемо))))) rainarr ну дык то же самое - кол-во точек умножить на шаг - и в марджин-лефт подставляется)
Да ты гений просто ;-) Ещё можно использовать 16-ричный формат. Например: Код (Text): 01-000 01-001 01-001-1 ... 01-001-a 01-001-f ... 0e-fff Или даже какой-нибудь 27-ричный. Человеку всё равно это не разгребать, а для сортировки и уплотнения данных удобно. А количество разрядов зависит от максимального количества записей на уровень. Если количество записей выходит за рамки ff (в первой цифре), то просто всем добавляется "0" (это придётся редко делать, т. что не страшно). Плюсы такого метода: 1. Удобно сортировать; 2. В самом пути заложена иерархия; 3. Сразу видна глубина вложенности; 4. Легко найти предка, прапредка... главного предка; 5. Легко вывести дерево с нужной глубиной вложенности. Минусов не замечал. Возможно, на сайтах с миллионами страниц и с постоянным удалением/перемещением записей будет сильный загруз.