Подскажите как сделать оптимальный запрос для такой таблицы

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

Непонятен вопрос. Во-первых как вы собираетесь складывать name и total, во-вторых что выдавать, когда в двух стоках для данной даты id+total максимально и одинаково, а name различается? Две строчки выдавать? Возможно, если вы потрудитесь и правильно сформируете вопрос, то ответ сразу будет ясен.

а если у максимального ID будет немаксимальный TOTAL или наоборот?
и что значит максимальный NAME?

Извините я неправильно выразился

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

может так будет понятно:
что б он выдал  неповторимые даты с максимальным id и поля name и total которые принадлежат записи с номером id
ЗАРАНЕЕ СПАСИБО!!!

Может вложенный запрос прокатит? В MS SQL такое работает:

Спасибо! Работает только очень медленно, может есть еще какой-то способ?

Если нету, то создать индекс по id и date. Должно ускорить.

> [6] palva ©   (14.12.08 21:34)
> то создать индекс по id и date

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

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

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

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

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

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

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

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

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

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

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

Почему?

Потому что поиск только по ID, а ID в составном индексе на 2-м месте. Значит не может использоваться. Чтобы использовался - нужно условие и по дате.

> [12] ANB   (15.12.08 15:46)

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

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

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

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

Для подзапроса то действительно, будет выгоднее дата+ID.
Если вообще индекс будет нужен. В таблицу то все равно лезть.

> [14] ANB   (15.12.08 15:54)

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

не нужен тут индекс, вреден, нужно что-то типа hash или merge join

>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, например, это записывается так(хинты - для того, чтобы подчеркнуть логику, согласно которой сервер обрабатывает запрос. более, чем вероятно, что оптимизатор сам построит именно этот план):


в (t) индекс, действительно, ни к чему, но по ID должен быть, т.к. в этом случае получим вполне уместный NL, где в качестве ведущей таблицы выступает (t) и данные из (t2) берутся строго по index unique scan.

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

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

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