я не понимал разницу между всеми join'ами, поэтому везде исползовал left join. Сейчас прочитал еще раз внимательно, дошло. Запрос еще проще выглядит.
фильтрация по VD.SR случайно попала, я просто скопировал со старого решения.

на счет группировки аналогично, мне казалось я все испробовал, только VD.KK работало. Сейчас сгруппировал по KL.KK, получилось. В общем, задача:

старое решение

новое решение

только функция avg не выдает 0, если книгу не брали..

Я именно так и понял, потому и был так настойчив 


Чисто чтоб закрепить - я как-то рисовал картинку. Мне кажется достаточно доходчиво должно бы быть. 


  
Осталось одно только замечание. Это будет работать только на MySQL.

Стандарт SQL запрещает в списке полей select использовать поля, не перечисленные в group by без применения к ним аггрегатных функций. MySQL единственный из известных мне движков не реализует этого запрета. Разработчики отписываются, мол это для оптимизации, и ограничивают область использования этой фичи в документации. 

Соответственно, чтобы оторваться от диалекта MySQL вам осталось лишь выдержать это ограничение заменив 

на


Добавлено через 4 минуты и 39 секунд



Тут, кстати, тонкий момент. VD.SR может принимать неопределенное значение, и если оно используется, функция avg его не будет использовать при расчете. avg([1,null]) = 1, в то время, как avg([1,0]) = 0.5. Но в постановке задачи этот ньюанс не огооврен, думаю, можно забить(но держать в уме, я бы такой вопрос поднял бы на защите)

хорошие картинки, как-то давно натыкался на подобное, только там круги были. Тогда не сохранил и забыл где видел, а вашу картинку сохранил на комп)


я так понял здесь без разницы что max, что min использовать? лишь бы была какая-то функция?


получилось) только у преподавателя даже нет возможности спросить/проконсультироваться. На дистанционке учусь.

вот еще пару запросов сделал, может есть какие-то замечания..






остались 2 задачи, которые никак не получаются.

сделал вот так:

но здесь мешает HAVING COUNT, потому что он считает, что должно быть больше 10 записей, которые брались больше чем на 30 дней. Т.е. сначала выполняется WHERE, отсеивает часть, потом по оставшимся уже проходится HAVING COUNT. А надо как-то, чтобы они вместе работали, например WHERE VD.SR > 30 and count(VD.K) > 10, но тогда GROUP BY мешает.


эм.. тут я даже не представляю как должен вывод выглядеть, речь о 2х разных списках идет. Что-то такого что ли:
- Иванов, Петров, Сидоров - Горе от ума (3)
- Иванов, Козлов - Евгений Онегин (2)
и т.д.
разве такой список можно сделать только одним запросом?

в общем, я бы, наверное, прошелся по списку книг, у каждой проверял кто ее брал, если ее брали > 1 человека, то выводить ее..

  т.к. у нас группировка по первичному ключу.


тут не знаю. Я пишу на оракле. Оракл не умеет делать жойн для делита. not in или not exists с моей точки зрения выглядило бы как более универсальное решение. C not in - ньюанс: применимо только к not nullable набору данных.

Здесь возможна неоднозначность трактовки задачи
1) Книга бралась более 10 раз и всякий раз на срок не менее 30 дней, тогда ваш подход - правильный
2) Книга бралась более 10 раз на общий срок не менее 30 дней, тогда суммируем сроки и отсекаем в havind

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

В принципе - то же самое. Группироваться по паре (id_клиент,id_книга)

у меня серьезные проблемы с пониманием условий %) перечитал 200 раз и до меня дошло, что "Список клиентов, бравших одну и ту же книгу" эту фразу я не так понимаю, думал что нужно найти общие интересы клиентов)) в общем сделал вот так

все работает как надо.

Zloxa, спасибо вам огромное. Без вас бы не разобрался. Поставил бы плюсик к каждому посту, но пока 100 сообщений не набрал, нельзя плюсики ставить.

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

Это сообщение отредактировал(а) Zloxa - 11.3.2012, 14:20

Так то это тоже просто. 

Селфджойн:

получаем список общих интересов