подучиваюсь, решаю задачки. есть таблица:
статьи(идентификатор,автор,данныеостатье)
идентификатор - уникальный. надо составить запрос, который выведет автора, у которого больше всего статей.
это не подвязано к какой-то БД, "чистый" SQL.
можно юзать: select,view,count(),max(),union,intersect,except и т.д.
можно делать несколько views.
создал view:

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

понял, что надо:

a потом:


получается.

Если одним запросом:

select идентификатор, автор, данныеостатье
from TABLE
where идентификатор in (select max(COUNT_FIELD) from (select count(автор) as COUNT_FIELD from TABLE group by автор))

С использованием процедур:

зависит от СУБД 

Это сообщение отредактировал(а) while - 29.7.2008, 00:32

while, извините за вопрос: я ошибаюсь, или вы предположили что имя таблицы - "TABLE".
я новичок в SQL, но ужасно дотошный индивид!

Конечно, предположил. TABLE - некоторая таблица... 

т.е.вашим путём я получаю:

но с т.з. временной сложности (т.е. эффективности) оба решения идентичны... 
или нет ?

Да.



А вот это уже отчасти зависит от СУБД, кол-ва записей, наличия индексов и т.д. . К тому же view еще нужно создать. И если он нужен для одного запроса, то .... ? 

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

Это сообщение отредактировал(а) while - 29.7.2008, 01:08

Товарищ просил 

а как там с подзапросами?
К тому же не требуется инфа по самим статьям - потому вьюв по авторам, который написАл bilbobagginz, одновременно является и требуемым запросом.

насколько я понял задание - в "нашем" SQL есть подзапросы.

Ну так выведет всех авторов в порядке уменьшения количества статей. Если нужен один, который самый плодовитый, следует дополнительно использовать ограничение по количеству. А как оно будет выглядеть - TOP 1 или там LIMIT 1 - зависит от диалекта.

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

Это сообщение отредактировал(а) Akina - 30.7.2008, 18:04

Akina, хмм.. упрощаться-то он упрощается, только вот вопрос: в чем тут выгода.
не может же быть, что всё прям так в шоколаде ?
чем я заплатил (кроме мысли) создав 2 вью ?

зависит от оптимизатора.
в случае сложных многоуровневых запросов я бы убедился, что "вьюшность" запроса не мешает оптимизатору выбирать подходящие индексы.
кроме того, некоторые(скорее всего - все) СУБД(MSSQL - точно, проверено опытом) накладывают ограничения на количество вьюшек в одном запросе(а если у тебя вьюшки на вьюшках созданы, то вполне безобидный с первого взгляда запрос может не выполняться...)

Это всё конечно хорошо, но давайте спустимся не грешную землю и возьмем ситуацию из реальной жизни. Несколько авторов написали несколько статей от 2 до 5 к примеру, но Петров написал 10 статей и Петров не отстал в количестве, то есть тоже 10 написал.
Рассматривая запросы:

Получим обоих авторов, как и надо. Мы же других критериев отбора не вводим.
А кого мы получим используя
можно угадать с вероятностью 50/50, но только Иванова или только Петрова.

Для MS-SQL в данном случае используется: