|
|
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
CODE - тип изделия, COLOUR - цвет изделия SELECT CODE, COLOUR FROM ITEMS GROUP BY CODE HAVING COUNT (*) > 10 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 12:29:28 |
|
||
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
Подскажите пожалуйста, насколько корректен данный запрос? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 12:30:47 |
|
||
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
d3us, нет, хотя мускль по умолчанию подобное допускает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 12:30:50 |
|
||
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
tanglir, ничего не понял :) Нет, но sql допускает, это как? :) Так HAVING будет фильтровать CODE со значением больше 10 или запрос написан некорректно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 12:32:35 |
|
||
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
d3usНет, но sql допускает, это как?А вот так :) Синтаксически он некорректен. Но my sql такие запросы выполнять не отказывается, в отличие от большинства других скл-СУБД. Касательно вопроса "почему" - 13173672 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 12:39:12 |
|
||
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
d3usHAVING будет фильтровать CODE со значением больше 10Будет, только не "со значением", а "с количеством записей", и не code, а результат группировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 12:40:43 |
|
||
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
tanglird3usНет, но sql допускает, это как?А вот так :) Синтаксически он некорректен. Но my sql такие запросы выполнять не отказывается, в отличие от большинства других скл-СУБД. Касательно вопроса "почему" - 13173672 Запрос синтаксически корректен, он некорректен семантически. Поле COLOUR не входит в GROUP BY и не агрегируется. Откуда его брать -- неизвестно. Обычно в SQL такое недопускается (не знаю, как по стандарту, но многие СУБД просто выдают однозначно ошибку). Но MySQL такие запросы пропускает, как он себя при этом ведёт -- не знаю, потому как никогда такой хренью не интересовался, да и тебе не советую. А советую все неагрегаты помещать в GROUP BY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 13:14:28 |
|
||
|
Корректен ли запрос?
|
|||
|---|---|---|---|
|
#18+
На самом деле в MySQL реализовано расширение группировки, позволяющее не включать в GROUP BY повторяющиеся поля итоговой выборки. При правильном использовании это весьма удобно, но беда в том, что допускается и неправильное использование этой фичи. Пример: id1val11100id2id2_Tab1val2111021203130Тогда для Код: sql 1. 2. 3. Получим итогid1val1id2id2_Tab1val2110011101100212011003130 В MySQL можно написать запрос Код: sql 1. 2. 3. 4. В этом случае MySQL берет данные для Tab1.val1 из произвольной (первой попавшейся) строки внутри группы по Tab1.id1, и абсолютно прав так как все остальные поля из Tab1 в этой группе одинаковые. Стандарт же SQL требует явного перечисления всех полей tab1 в списке группировки, что утяжеляет понимание запроса Беда в том, что внутри этой группы по Tab1.id1 строки из Tab2 разные, но MySQL не обращает на это никакого внимания, и по-прежнему берет из группы произвольную строку, что приводит к неоднозначности запроса Код: sql 1. 2. 3. 4. id1val1qtyval21100310? 20? 30? непредсказуемо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2013, 13:51:50 |
|
||
|
|
start [/forum/topic.php?fid=47&msg=38511969&tid=1835488]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 190ms |
| total: | 301ms |
| 0 / 0 |
