Структура таблиц БД для хранения цепочек ответов к постам

Админ

20.05.15

✎

13:29

Как хранить в БД сообщения пользователей, которые являются ответами на другое сообщение, чтобы потом было удобно осуществлять вывод этих цепочек? И как реализовать вывод?

Примеры: 4pda, habr, pikabu

1 degot

20.05.15

✎

14:05

гугли про нереляционные бд

2 Fragster

гуру

20.05.15

✎

14:09

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

3 МаксимМП23

20.05.15

✎

14:14

(0) Таблица с сообщениями. У таблицы реквизит "ОтветНа" ссылка на сообщение (например на таймстамп, если уникальны).
Если ОтветНа пустой, значит корневое сообщение. Иначе - ответ на конкретное сообщение.

4 Fragster

гуру

20.05.15

✎

14:17

(3) а теперь получи всю цепочку запросом ;)

5 Лефмихалыч

20.05.15

✎

14:18

(0) гугли nested sets

6 МаксимМП23

20.05.15

✎

14:25

(4) Нда, не совсем кошерно.

Ну тогда в справочник сохраняться. Там иерархия есть.

7 Fragster

гуру

20.05.15

✎

14:26

да, в (5) правильное название. еще есть materialized path, но там своих ограничений хватает

8 DirecTwiX

20.05.15

✎

14:38

Всем спасибо, будем читать.

(6) Да справочник - это та же структура, что и в (3).
Непонятно, как всю цепочку получить запросом.

9 Garykom

гуру

20.05.15

✎

15:00

Для реляционных таблиц самое простое это составной id

Т.е. длину id делаем побольше и при записи хитро заполняем

упрощенный пример для ограничения в 3 уровня вложенности и кол-во собщений в уровне

100 1 пост
101 2 пост подчиненный 1
102 3 пост подчиненный 1
200 4 пост сам по себе
300 5 пост сам по себе

ЗЫ лучше id делать простые по порядку и отдельно хранить табличку с подобными "кодами подчиненности"

ЗЗЫ можно сделать быстро-работающе но много места-жруще
через хранение в таблицах id всех родителей для каждого конечного поста

10 МаксимМП23

20.05.15

✎

15:10

(8) "В ИЕРАРХИИ" же

11 qeos

20.05.15

✎

15:11

(9) составной id это неправильный путь..

100 1 пост
101 2 пост подч 1
102 3 пост подч 1
ххх? 11 пост подчинен 102

(0) самый верный - это как в (3).. реквизит "Владелец"..
"как получить запросом?" -- рекурсионно
гуглить "дерево в таблицах sql"
например на хабре http://habrahabr.ru/post/43955/

12 Fragster

гуру

20.05.15

✎

15:11

(9) это и есть materialized path

13 qeos

20.05.15

✎

15:11

(10) а чо так тоже можно было? там чо 1с?

14 Fragster