Mysql помощь

[Hector]

Нужно выбрать коменты по ID и ответы на них (PID) и отсортировать по дате добавления главного сообщения.

Есть таблица.

id | message | pid | date

Но еще есть LIMIT 20 OFFSET 100 (постраничный вывод коментов).

Короче должно быть так:
1. Главное сообщение (дата 01.2013)
- комент (дата 12.2012)
- комент (дата 10.2012)
- комент (дата 05.2012)
- ...
2. Главное сообщение (дата 12.2012)
- комент (дата 01.2013)
- комент (дата 11.2012)


Ну и так далее. В таблице они идут все под своим id. Обратите внимание на даты. Выборка идет с LIMIT и OFFSET.

Пример коментов вот тут http://www.drive2.ru/users/mersbrabus/blog/246513/#post
Только мне нужно в обратном порядке (новые сверху).

[ulitka]

Сообщение от flo0

для хранения и управления деревьями люди придумали MPTT

хуйню они придумали
чтобы создать/удалить 1 запись надо пересчитать всё дерево

[flo0]

ну изобрети более эффективный метод для структур с неограниченной вложенностью. Многие тебе скажут спасибо

Пересчитывать границы можно одним запросом, это типа дешевле чем гонять рекурсивные запросы на выборку

[Drunk Monk]

Так зачем на всю глубину за один запрос вынимать? Третий уровень аяксом подгружать лучше

[chesser]

Сообщение от flo0

для хранения и управления деревьями люди придумали MPTT

+1

но зависит от ситуации, я чаще использую Materialized Path
http://www.opennet.ru/docs/RUS/hierarchical_data/

нужно одним запросом все вынимать - так самое правильное имхо, но для этого структура неправильная. Придется рекурсивно ходить по дереву, используя 100500 sql-запросов, убивая сервер.....но объектное кеширование спасет, да

[ulitka]

Сообщение от flo0

ну изобрети более эффективный метод для структур с неограниченной вложенностью. Многие тебе скажут спасибо

варианты есть, зависит от задачи. правильно спроектированная БД залог успеха
а пересчитать всё дерево или обыскать всё дерево последовательно это а не вариант
на малых объёмах только

[Hector]

Пацаны дерево строится. Мне нужно результаты в БАЗЕ подтянуть чтоб id было рядом с pid. Понимаете?
id
-pid
-pid

id
-pid


Иначе pagination сжирает ответы, так как сортируется по времени добавления. И он не подтягивает ответы на старые коменты. Если не понятна задача могу еще раз пояснить.

[chesser]

Сообщение от ulitka

варианты есть, зависит от задачи. правильно спроектированная БД залог успеха
а пересчитать всё дерево или обыскать всё дерево последовательно это а не вариант
на малых объёмах только

есть 3(4) популярных алгоритма (см выше) для хранения/обработки иерархических структур данных с помощью реляционных. Т.е. речь идет о трансформации иерархической модели данных в реляционную. Эти алгоритмы отличаются как раз вариантами/условиями их использования: одни лучше для чтения, другие для модификации и тд.

Либо можно использовать алгоритмы и их реализации, изначально приспособленные под иерархические данные, например, xml и native xml databases.

О каких вариантах говоришь ты - не понятно. Приведи пример?
Я к тому, что при отклонении от этих алгоритмов, скорее всего ты получишь проигрышь в оптимальности решения.

[ulitka]

Сообщение от chesser

есть 3(4) популярных алгоритма (см выше) для хранения/обработки иерархических структур данных с помощью реляционных. Т.е. речь идет о трансформации иерархической модели данных в реляционную. Эти алгоритмы отличаются как раз вариантами/условиями их использования: одни лучше для чтения, другие для модификации и тд.

Либо можно использовать алгоритмы и их реализации, изначально приспособленные под иерархические данные, например, xml и native xml databases.

О каких вариантах говоришь ты - не понятно. Приведи пример?
Я к тому, что при отклонении от этих алгоритмов, скорее всего ты получишь проигрышь в оптимальности решения.

варианты от задачи зависят. иногда можно изначально так спроектировать БД, что упростишь себе жизнь сразу и навсегда
под конкретную задачу гектора я предложил идею выше.
я смотрел твою ссылку, чем тебе те варианты не нравятся? там есть получше, чем предложенный выше nested set, который годится под статику только или мелкие базы
под статику и у самого мускуля тоже есть оптимизатор
статика она такая, оптимизируемая
ещё тут читал интересный вариант

[chesser]

Сообщение от ulitka

варианты от задачи зависят. иногда можно изначально так спроектировать БД, что упростишь себе жизнь сразу и навсегда

не согласен, т.к. задача недвусмусленна: обработка/хранение иерархической структуры данных. Цель - найти оптимальное решение. Условия - они не были озвучены до конца, не было сказано о характере запросов и их частотном распределении (чтение/редактирование(удаление)). Также не было предъвлено требований к производительности системы.
Одно лишь правильное проектирование БД не поможет в решении этой задачи обработки иерахических структур данных, т.к. проектирование БД - это часть реализации, не более того. Сам алгоритм стоит НАД реализацией.
Если ты говоришь об изменении самой постановки задачи и ее цели - это уже другой разговор.

Конкретно в данном случае я бы не парился в поисках оптимальных решений и закешировал бы все в объектный кеш, или даже в html статику, если там анонимов много.

Сообщение от ulitka

сразу и навсегда

ни разу такого не видел

Сообщение от ulitka

ещё тут читал интересный вариант

если то про первый алгоритм из статьи, то это Materialized path о котором я писал выше, его я чаще всего и использую у себя под свои задачи, но иногда nested set

[Boodda]

да все решается гораздо проще, ставим Postgresql пишем тригер на внесение/апдейт коммента, у вышестоящего комента запоминаем ID подчинённых комментов в поле с типом ARRAY, и догоняем это все хранимой процедурой рекурсивного обсчёта при селекте.