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

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

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

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

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

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

(0) гугли nested sets

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

(11) если больше писать - то верный способ Adjacency List (как в 1с), если больше читать - то верный способ Nested Sets, Materialized Path посередине

http://www.opennet.ru/docs/RUS/hierarchical_data/