комплексен sql подреждане по

Предполагам, че "идентификатор на отговора" е 0 за статии и е номерът на статията за коментари. Ако това е вашият дизайн, това трябва да работи:

select * from yourTable
order by
  case when "reply id" = 0 then id else "reply id" end, id

ДОБАВЕНО: Благодаря за допълнителната информация във вашия коментар. Да поставите резултатите в реда, който искате, не е толкова лесно, защото първият ключ за подреждане е created_date на публикацията за стартиране на нишката. Това не е в реда с данни, така че имате нужда от присъединяване. Ето най-доброто ми предположение въз основа на допълнителната информация (която все още не е достатъчно пълна, за да не гадая):

select
  f.id, f.user_id, f.type, f.reply_id, f.text, f.url, f.created_date,
  coalesce(parentfeed.created_date,f.created_date) as thread_date
from feed as f left outer join feed as parentfeed
on f.reply_id = parentfeed.id
order by
  thread_date desc,
  case when f.reply_id = 0 then 0 else 1 end,
  created_date desc, id;

Може да се наложи да коригирате синтаксиса за postgre. Тествах това в SQL Server.

Ако това все още не прави това, което искате, моля, посочете точно как искате данните обратно. За предпочитане е да ми кажете реда "id", който трябва да видя за данните във вашия файл за дъмп, и също обяснете основата на тази поръчка. Ето какво направих:

1. Всички съобщения в нишката (нишка =съобщения и нейните коментари) трябва да бъдат групирани заедно.

2. В рамките на нишка поставете съобщението отгоре, последвано от коментарите му в обратен хронологичен ред. Нишката с най-скоро създадена/_дата трябва да бъде първа, след това нишката с втората най-скоро създадена_дата и т.н. (Вашите примерни данни имаха много коментари с една и съща created_date, така че използвах „id“ като вторичен ключ за поръчка за коментарите в нишката.)

Забележка: Вашият дъмп показва, че created_date се актуализира до CURRENT_TIMESTAMP, ако публикация е променена. Ако това е табло за съобщения на живо, имайте предвид, че това може да доведе до дата на коментарите преди родителското съобщение и това означава, че нишката ще остане отгоре, ако често се променя (дори и без действителна промяна в текста й). (Това не е от значение за моето решение, но реших, че си заслужава да се отбележи.)

Тъй като се изисква присъединяване, тази заявка вече ще бъде много по-бавна. Моето предложение:поддържайте две колони за дата, "thread_last_modified" и "item_last_modified". Ще трябва да каскадирате актуализации от стартиращи нишки към коментари, но мисля, че си струва, ако няма много актуализации, защото заявката може да бъде много по-проста. Не съм тествал това, защото изисква няколко промени във вашия дизайн:

select
  id, user_id, type, reply_id, text, url, thread_last_modified, item_last_modified
from feed
order by
  thread_last_modified desc,
  case when f.reply_id = 0 then 0 else 1 end,
  item_last_modified desc, id;

ДОБАВЕНО №2 :Ако искате само нишката, съдържаща коментара с идентификатор ::thisOne, мисля, че можете да добавите този ред между клаузите ON и ORDER BY (за първото ми добавено решение, присъединяването):

where parentfeed.id = (
  select coalesce(reply_id,id)
  from feed
  where id = ::thisOne
)

На теория това търсене трябва да бъде оценено само веднъж за заявката, но ако не е на практика, можете да го изчислите предварително като ::thisOneThreadID и да добавите

where parentfeed.id = ::thisOneThreadID

За второто решение, ако приемем, че предварително изчислите отново, опитайте

where coalesce(id,reply_id) = ::thisOneThreadID

Между другото, подозирам, че и двете ми решения ще обединят нишки, които са били последно променени по едно и също време...