Добрый день!

Помогите, пожалуйста решить проблему.Есть таблица, например :

-------------------------------------
| ID   |    A      |    B    |    C    |
-------------------------------------
|   1  |     1      |   a    |     b    |
|   2  |     2      |   a    |     b     |
|   3  |     3      |   b     |    c     |
|   4  |     4      |   b    |     c    |
.....

Нужно выбрать все записи с максимальным значением столбца "А" по столбцу "B" ..
Чтобы получилось :

-------------------------------------
| ID   |    A      |    B    |    C    |
-------------------------------------
|   2  |     2      |   a    |     b     |
|   4  |     4      |   b    |     c    |
.....

я что-то туплю ....
Подскажите, как сделать такой SELECT ?

Спасибо.



Это сообщение отредактировал(а) ZMaximI - 18.12.2007, 18:30

Так что сравнивай как обычные числа

если А - уникальные, то можно простой группировкой.
а если нет...

Добавлено через 1 минуту и 27 секунд
Akina, ты не получишь из этой выборки ни id, ни C
если они не нужны, а только А и В - то конечно

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

в том-то и дело, что "А" не унакально ..

Это сообщение отредактировал(а) ZMaximI - 18.12.2007, 18:53

Сколько угодно... если текущая версия MySQL (которую ты не озаботился указать) поддерживает подзапросы.

извини MySQL 5.0

-------------------------------------
| ID   |    A      |    B    |    C    |
-------------------------------------
|   1  |     1      |   a    |     b    |
|   2  |     2      |   a    |     b     |
|   3  |     2      |   a    |     с     |

Такой вариант таблицы возможен?
если да, то какую запись выбирать из двух последних?

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

вот структура таблицы :



в этой таблице храняться расчитанные данные за каждый день, НО пользователи могут запустить расчет несколько раз за один день ...
следовательно мне нужно выбрать последний расчет - выбрать все записи с максимальным значением CALC_DATE и CALC_TIME, при этом должна быть обязательная группировка по DEPO_MAN1, т.к. в этом поле данные будут повторяться с каждым запуском расчета ...

странная таблица. не укладывающаяся в реляционные каноны, как я их понимаю.
если пользователь что-то посчитать может - то почему сервер то же самое посчитать не может?
обычно бд не используется для хранения результатов вычислений. А только для хранения исходных данных для этих вычислений.

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

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

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

Всем спасибо, за идеи.

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

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

В MySQL вполне можно... но это однозначный filesort

Еще раз, всем спасибо.
Вопрос закрыт.