Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

select неповторяющихся записей [D7, IB6.x]

Страницы: 1 2 >
dest81 © (2008-12-14 19:11:00)
Подскажите как сделать оптимальный запрос для такой таблицы

id date name total
1 20.08.08 petya 20
34 20.08.08 petya 35
3 22.08.08 petya 20
44 22.08.08 petya 60

что б он выдал неповторимые даты с максимальным id +name+total:

id date name total
34 20.08.08 petya 35
44 22.08.08 petya 60

Petr V. Abramov (2008-12-18 13:47:00) [1]

> Кщд (18.12.08 07:43) [25]

я идею написал, понятно, что надо еще чуть-чуть букв :)

Кщд (2008-12-18 07:43:00) [2]
>Petr V. Abramov © (17.12.08 23:29) [24]
>тогда
>select first_value("date") over (order by id,name,total)
>from хрен_знает
так мы получим ВСЕ данные из "хрен_знает" + last_value(id) over (partition by "date" order by id)

Petr V. Abramov (2008-12-17 23:29:00) [3]

> отдельно оговаривалось, что речь об oracle

тогда
select first_value("date") over (order by id,name,total)
from хрен_знает

Кщд (2008-12-17 11:24:00) [4]
MsGuns © (16.12.08 22:26) [22]
>А что, ИБ уже научили понимать вложеные запросы ?
отдельно оговаривалось, что речь об oracle
обсуждение началось с того, что использование индексов в данном случае нерационально

>SELECT * FROM table1 WHERE id IN (SELECT MAX(id) FROM table1 GROUP BY date)
речь шла об этом и только об этом запросе, а его IB6 должен бы понять

в моем примере (Кщд (16.12.08 07:11) [18]) запрос был написан в форме, в которую указанный выше select будет преобразован oracle'ом при построении плана

MsGuns (2008-12-16 22:26:00) [5]
>Кщд (16.12.08 07:11) [18]

А что, ИБ уже научили понимать вложеные запросы ?

ANB (2008-12-16 17:13:00) [6]

> здесь же NL будет всегда [b]не хуже[/b], hash join для t
> и t2

Пробовать надо.

> это даст радикальный прирост по скорости

Согласен.
Не больше чем в 1.5-2 раза. Во всяком случае СОЗДАВАТЬ индекс для отчета смысла нету. Если уже есть - то можно использовать, будет немного шустрее.

Кщд (2008-12-16 13:11:00) [7]
>ANB (16.12.08 12:56) [19]
>FFS пошустрее будет. Проверялось.
в данном случае(индекс по date + id) придется пройти все листовые блоки, а т.к. такой индекс(по причине уникальности) содержит столько листовых элементов, сколько записей в table1(считаем, что id и date - not nullable).
пошустрее - это да, согласен, т.к. будет читать данные по порядку по листам индекса, а не метаться между блоками таблицы.
однако, вовсе не уверен, что это даст радикальный прирост по скорости).

>А вот NL - это, как я уже говорил, зависит от количества ID на одну дату. HASH может оказаться лучше.
здесь же NL будет всегда [b]не хуже[/b], hash join для t и t2

ANB (2008-12-16 12:56:00) [8]

> по такому индексу будет FFS - чем это лучше table access
> full в данном случае?

FFS пошустрее будет. Проверялось.
Но. Если нужен только один отчет по такому индексу и больше он не нужен нигде, то фулл-сканн однозначно лучше. Согласен.

А вот NL - это, как я уже говорил, зависит от количества ID на одну дату. HASH может оказаться лучше.

Кщд (2008-12-16 07:11:00) [9]
>ANB (15.12.08 15:56) [15]
>Для подзапроса то действительно, будет выгоднее дата+ID.
по такому индексу будет FFS - чем это лучше table access full в данном случае?

>Petr V. Abramov © (16.12.08 01:36) [17]
>не нужен тут индекс, вреден, нужно что-то типа hash или merge join
в oracle, например, это записывается так(хинты - для того, чтобы подчеркнуть логику, согласно которой сервер обрабатывает запрос. более, чем вероятно, что оптимизатор сам построит именно этот план):
select /*+ ordered use_nl(t t2) */ t2.* from (select max(t2.id) id from table1 t2 group by t2.dt ) t join table1 t2 on t.id = t2.id
в (t) индекс, действительно, ни к чему, но по ID должен быть, т.к. в этом случае получим вполне уместный NL, где в качестве ведущей таблицы выступает (t) и данные из (t2) берутся строго по index unique scan.

Petr V. Abramov (2008-12-16 01:36:00) [10]
не нужен тут индекс, вреден, нужно что-то типа hash или merge join

Sergey13 (2008-12-15 15:59:00) [11]
> [14] ANB (15.12.08 15:54)

Согласен, про фул скан я кажется погорячился, но по любому для подзапроса индексом стОит поиграться. Тем более, что по ИД он наверное так и так есть.
Только автору эта тема видимо уже не интересна.

ANB (2008-12-15 15:56:00) [12]
Для подзапроса то действительно, будет выгоднее дата+ID.
Если вообще индекс будет нужен. В таблицу то все равно лезть.

ANB (2008-12-15 15:54:00) [13]

> А внешний запрос тут так и так пойдет фулсканом, ИМХО.

Если будет индекс по ID - зачем ему идти фуллсканом.

Вообще тут надо смотреть на количество ID в одной дате. Если много (больше 100) - надо цеплять индексы. Если 2-3 - однозначно фуллсканн с хэш-джойном будет шустрее. Если что то среднее - надо пробовать так и эдак.

Sergey13 (2008-12-15 15:49:00) [14]
> [12] ANB (15.12.08 15:46)

Я говорю про подзапрос. Он при правильно подобранном индексе будет (должен) выполняться без участия таблицы.
А внешний запрос тут так и так пойдет фулсканом, ИМХО.

ANB (2008-12-15 15:46:00) [15]
Потому что поиск только по ID, а ID в составном индексе на 2-м месте. Значит не может использоваться. Чтобы использовался - нужно условие и по дате.

Sergey13 (2008-12-15 15:40:00) [16]
> [10] ANB (15.12.08 15:21)
> date+id - не сможет использоваться в основном запросе.

Почему?

ANB (2008-12-15 15:21:00) [17]

> Sergey13 © (15.12.08 14:47) [9]

Можно даже не пробовать.

date+id - не сможет использоваться в основном запросе.

Впрочем, на оракле я бы вообще выбросил индексы и сделал на фулл-сканах. Был бы самый шустрый вариант.

Sergey13 (2008-12-15 14:47:00) [18]
> [8] ANB (15.12.08 14:06)
> Не поможет.
Не факт. Пробовать надо. Тут задача, ИМХО, ускорить подзапрос, а для этого желательно заставить его работать без таблицы, с одним индексом. С моим вариантом индекса это кажется будет проще. Но... пробовать надо.

ANB (2008-12-15 14:06:00) [19]

> В этом случае, ИМХО, логичней будет date+id.

Не поможет. В наружном запросе надо по ID, во внутреннем - по дате.

Так что прав палва.

Хотя, если в таблице записей не много - должно и так работать. Но это уже от СУБД зависит.

Sergey13 (2008-12-15 09:37:00) [20]
> [6] palva © (14.12.08 21:34)
> то создать индекс по id и date

В этом случае, ИМХО, логичней будет date+id.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »