Как вывести в грид записи в порядке обратном физическому ?

← →
Sergey Vorobyev (2004-06-08 16:09) [0]

Известно что, если выполнить запрос вида
select * from mytable
то записи выведутся в физическом порядке, т.е. так как они
расположены в таблице..

Возможно ли сделать так, чтобы вывести их в обратном порядке,
т.е. с конца и к началу,
не делая fetch всех записей и не добавляя order by (долго)

Примечания:
База данных Interbase/Firebird/Yaffil, для запроса использую TIBQuery.

Некоторое пояснение задачи:
Некий контроллер пишет в базу данных, порядок записей соответствует
временнОму порядку, т.е. более поздняя запись физически будет расположена
"ниже".
Необходимо вывести для пользователя последние записи..
Если это делать путем order by то это будет долго, тогда как просто select * выводит все очень быстро (практически мгновенно), а число записей порядка миллиона

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

← →
Alexandr (2004-06-08 16:16) [1]

1) физического порядка не существует. Это иллюзия.
2) Сортировка всегда нужна для любого упорядочивания.
Если нет сортировки, то набор данных неупорядоченный. И думать, от том что он упорядочен в физическом порядке опасно.
3) чтоб сортировка работала быстро нужен индекс.
4) чтоб получить последние несколько записей нужно добавить условие типа where id<maxid-20. Подробнее нельзя написать, ибо непонятно чего у тебя там.
5)

← →
Ratiborr © (2004-06-08 16:23) [2]

Не знаю как в Interbase, не работал. А в Paradox"е для готовых наборов данных я создавал индексы с нужным мне упорядочиванием. Может и там попрет...

← →
Sergey Vorobyev (2004-06-08 16:36) [3]

> 1) физического порядка не существует. Это иллюзия.

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

> 2) Сортировка всегда нужна для любого упорядочивания.
> Если нет сортировки, то набор данных неупорядоченный.
> И думать, от том что он упорядочен в физическом порядке
> опасно.

Опять согласен, но если есть практически 100% гарантия, что
физический порядок записей соответствует, временнОму порядку, т.е.
уже упорядочен по времени, то почему бы этим не воспользоваться?
Тем более моя задача "не опасная", даже если случиться и не так,
что ОЧЕНЬ МАЛОВЕРОЯТНО.. Если сопоставить РИСК/ВЕРОЯТНОСТЬ, то
МОЖНО!!!

> 3) чтоб сортировка работала быстро нужен индекс.

В том то и дело, что так не получается.
Ну например, таблица с полями id, message, msg_datetime.
Сделаем индекс по msg_datetime.
Запрос вида select * from mytable order by msg_datetime desc все равно выполняется долго (все равно план NATURAL).
Или ты здесь имеешь ввиду нечто иное?

> 4) чтоб получить последние несколько записей нужно добавить
> условие типа where id<maxid-20

А вот это мне кажется хорошая идея на первый взгляд, может получиться очень быстро! Попробую..

← →
Соловьев © (2004-06-08 16:39) [4]

> Некий контроллер пишет в базу данных, порядок записей соответствует
> временнОму порядку

добавляешь поле TIMESTAMP - пиши туда дату и время записи, создай индекс по этому полю и делай себе выборку.

← →
Alexandr (2004-06-08 16:44) [5]

> > 1) физического порядка не существует. Это иллюзия.
>
> Вообще в теории нет, согласен, но если этим можно воспользоваться
> для
> решения задачи. то почему бы и нет..

можно. Но вот видишь, у тебя не получается.

>
>
> > 2) Сортировка всегда нужна для любого упорядочивания.
> > Если нет сортировки, то набор данных неупорядоченный.
>
> > И думать, от том что он упорядочен в физическом порядке
>
> > опасно.
>
> Опять согласен, но если есть практически 100% гарантия,
> что
> физический порядок записей соответствует, временнОму порядку,
> т.е.
> уже упорядочен по времени, то почему бы этим не воспользоваться?
> Тем более моя задача "не опасная", даже если случиться и
> не так,
> что ОЧЕНЬ МАЛОВЕРОЯТНО.. Если сопоставить РИСК/ВЕРОЯТНОСТЬ,
> то
> МОЖНО!!!
>

ну-ну...

>
> > 3) чтоб сортировка работала быстро нужен индекс.
>
> В том то и дело, что так не получается.
> Ну например, таблица с полями id, message, msg_datetime.
> Сделаем индекс по msg_datetime.
> Запрос вида select * from mytable order by msg_datetime
> desc все равно выполняется долго (все равно план NATURAL).
> Или ты здесь имеешь ввиду нечто иное?
>

если в order by указано desc то и индекс нужен desc.

>
> > 4) чтоб получить последние несколько записей нужно добавить
>
> > условие типа where id<maxid-20
>
> А вот это мне кажется хорошая идея на первый взгляд, может
> получиться очень быстро! Попробую..

пробуй пробуй. выберешь 4 выриант и создешь нужные индексы и нормально будет.
Возникает другая проблема. НИКОГДА НЕ ЗАЛИВАЙ ДАННЫЕ РЕАЛЬНОГО ВРЕМЕНИ НАПРЯМУЮ В БАЗУ ДАННЫХ. нужен промежуточный буфер.

← →
Sergey Vorobyev (2004-06-08 17:14) [6]

Все получилось!
Спасибо Alexander!

Сделал так:
select message, msg_datetime from mytable where id > (select gen_id(gen_mytable_id, 0) from onerecordtable) - 20 order by msg_datetime desc

Работает быстро даже без индекса (сортировать-то всего 20 записей)

Все комментарии Alexandr (08.06.04 16:44) [5]
принимаю как для общего случая, но
для меня сечас лучше так,
потому что,
так я уже сделал, и этим уже сейчас пользуются!

Пользователей же не интересует как должно быть реализовано,
а если подумать, то не думаю, что в течение года или больше,
что-нибудь в постановке задачи изменится, т.к. задача
"не развивающаяся". Есть уже база, заполняются данные, надо
только статистику..

← →
Alexandr (2004-06-09 06:14) [7]

хорошо. За затычку засчитывается :)

Как вывести в грид записи в порядке обратном физическому ? Найти похожие ветки