комплекс sql заказывает
Для маркировки каталога как пакет, Вам нужен файл, названный __init__.py, это помогает?
4 ответа
Я предполагаю, что «идентификатор ответа» равен 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», который я должен видеть для данных в вашем файле дампа, и также объяснят основу этого порядка. Вот что я сделал:
Все сообщения в цепочке (цепочка = сообщение и его комментарии) должны быть сгруппированы вместе.
Внутри цепочки поместите сообщение вверху, а затем его комментарии в обратном хронологическом порядке. Первым должен быть поток с самым последним созданным / _date, затем поток со вторым самым последним created_date и так далее. (В ваших данных примера было много комментариев с одной и той же created_date, поэтому я использовал id в качестве вторичного ключа порядка для комментариев в потоке.)
Примечание: Ваш дамп указывает, что created_date обновляется до CURRENT_TIMESTAMP, если сообщение изменено. Если это активная доска сообщений, имейте в виду, что это может привести к тому, что комментарии будут датированы до родительского сообщения, и это означает, что ветка останется наверху, если она часто изменяется (даже без фактического изменения в его текст). (Это не относится к моему решению, но я подумал, что это стоит отметить.)
Поскольку требуется соединение, этот запрос теперь будет выполняться намного медленнее. Мое предложение: поддерживайте два столбца даты: thread_last_modified и item_last_modified. Вам придется каскадировать обновления от участников потока к комментариям, но я думаю, что это того стоит, если обновлений не так много, потому что запрос может быть намного проще. Я не тестировал это, потому что это требует нескольких изменений в вашем дизайне:
....
упорядочить по (некоторый предикат, который верен для «основных комментариев», но не для последующих) desc, date desc
Поскольку вы не разъясняете, что отличает «основной комментарий», это все, что я могу для тебя сделать. Если, как в вашем примере, все основные комментарии имели reply_id , равное нулю, это может быть:
порядок по case reply_id = 0, затем 1 else 0 end desc, date desc
Обратите внимание, что использование оператор case, а не просто упорядочение по reply_id , необходим, потому что вы хотите, чтобы первое выражение имело одно и то же значение (а именно ноль) для всех неосновных сообщений, чтобы они сортировались исключительно по второму выражение, дата .
(О, если я понимаю вашу схему, reply_id действительно следует называть in_repky_to_id .)
Я не уверен в ваших требованиях, поэтому мой ответ - абстракция ... max - может потребоваться минимальное значение (опять же, я не совсем понимаю ваши требования)
select
y.column1
, y.column2
, y.column3
, y.datecolumn
from
(select
column1
, max(datecolumn) as rank_date
from tableA
group by column1) as x
inner join tableA y on x.id = y.id
order by x.rank_date, y...., y.... desc, y... asc, etc...
, если вы используете сервер sql, есть функция, вызываемая по row_number, которую вы также можете использовать.
Вот ссылка на представление иерархические данные в реляционной базе данных. http://dev.mysql.com/tech-resources/articles/hierarchical-data.html
Суть в том, что вам нужно присоединиться к таблице на столько уровней, на которые вы хотите пройти. В приведенных примерах данных было всего два уровня.
SELECT
f1.id AS `parent_id`,
f1.text AS `parent_text`,
f1.created_date AS `parent_created_date`,
f2.*
FROM
feed AS `f1`
LEFT JOIN feed `f2` ON (f1.id = f2.reply_id)
WHERE f1.reply_id = 0
ORDER BY f1.created_date DESC, f2.created_date DESC
;
Информация о родительской статье будет находиться в столбцах f1. *, А информация о дочерних элементах (ответы) - в столбцах f2. *.