powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Теоретический вопрос про JOIN + GROUP BY
16 сообщений из 16, страница 1 из 1
Теоретический вопрос про JOIN + GROUP BY
    #34811966
sycore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Допустим есть две таблицы:
CREATE TABLE A (
id SERIAL NOT NULL PRIMARY KEY,
name TEXT
);

CREATE TABLE B (
a_id INT REFERENCES A (id) NOT NULL,
value INT
);

И вот к примеру такой запрос:
SELECT a.id, a.name, max (b.value)
FROM a
LEFT JOIN b ON b.a_id = a.id
GROUP BY a.id;

не проходит, база (postgres) требует чтобы a.name фигурировал в выражении GROUP BY,
т.е. чтобы было

..
GROUP BY a.id, a.name
..

Спрашивается - с чего такое требование, если a.id есть UNIQUE (PRIMARY KEY)? Т.е. a.id достаточно чтобы опознать строку из таблицы A.

А то в итоге приходится дублировать названия полей из SELECT и ORDER в GROUP BY, неприятно..
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34812019
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все что есть в SELECT'е и НЕ ВХОДИТ в групповые ф-ии (max, min, avg...) должно быть перечислено в GROUP BY - это стандарт SQL.
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34812448
sycore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Все что есть в SELECT'е и НЕ ВХОДИТ в групповые ф-ии (max, min, avg...) должно быть перечислено в GROUP BY - это стандарт SQL.

Допустим, тогда сопутствующие вопросы:
1) Этому есть какое-то логическое объяснение? Ведь потенциально база может сделать вывод, что id - это UNIQUE и не морочить голову.
2) Есть возможность как-то это обойти - возможен другой вариант запроса где бы не пришлось дублировать названия полей?
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34812468
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если запрос большой и сложный (многотабличный) поиск id не так очевиден. Насколько мне известно обойти это никак нельзя.
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34812573
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО Вы слишком много хотите от базы.
Наличие ПК мало, надо знать,
- что он не отключен
- что он не бывал отключен
- что он не бывал в состоянии NOVALIDATE
- что он всегда был

То есть наличие ключа не гарантирует уникальности данных по нему на текущий
момент времени.
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34812690
sycore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Если запрос большой и сложный (многотабличный) поиск id не так очевиден. Насколько мне известно обойти это никак нельзя.
При чём тут поиск?
Я говорю про то что
GROUP BY a.id, a.name
и
GROUP BY a.id
суть одно и то же если a.id - уникальный.

>- что он не отключен
>- что он не бывал отключен
>- что он не бывал в состоянии NOVALIDATE
>- что он всегда был

> То есть наличие ключа не гарантирует уникальности данных по нему на текущий момент времени.
Интерееесно, а нафиг сдалась такая БД, которая не гарантирует уникальности и целостности на SELECT-выборках?

Если ключа UNIQUE не было, его нельзя выставить на не-уникальных данных.

Возможно ещё дело в варианте NULL, но primary key not null...
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34812802
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sycore
>- что он не отключен
>- что он не бывал отключен
>- что он не бывал в состоянии NOVALIDATE
>- что он всегда был

> То есть наличие ключа не гарантирует уникальности данных по нему на текущий момент времени.
Интерееесно, а нафиг сдалась такая БД, которая не гарантирует уникальности и целостности на SELECT-выборках?

Если ключа UNIQUE не было, его нельзя выставить на не-уникальных данных.



Неверно.
В Oracle ключ можно создать / включить с опцией NOVALIDATE - существующие
данные не проверяются
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34812948
sycore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dmidek

Неверно.
В Oracle ключ можно создать / включить с опцией NOVALIDATE - существующие
данные не проверяются

1) Насколько я знаю это не sql-стандарт, так что разруливанием ситуации когда в GROUP BY не хватает полей пусть занимается те, кто использует эту фичу. Это нормальное поведение.

2) Я говорю о поведении, когда доп.поля в GROUP BY запрашиваются даже если одно из полей UNIQUE (VALIDATE) - по-моему оно если не некорректно, то по крайней мере излишне.
Не то что бы оно портит жизнь, но как-то... "ненормализован" запрос чтоли.

3) В момент запроса база прекрасно знает в каком состоянии первичный ключ - можно легко сделать вывод о необходимости запроса доп. полей
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34813221
Lelikovich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dmidek
То есть наличие ключа не гарантирует уникальности данных по нему на текущий
момент времени.

видимо это зависит от СУБД, в FireBird нельзя добавить ключ к имеющимся данным если данные в комбинации полей создаваемого ключа не уникальны, поэтому требование перечисления всех полей не входящих в агрегатные функциив качестве полей группровки связано с реализацией той самой группировки, т.е сначала выбираем все что есть в селекте, затем группируем по комбинации полей в группировке .. имха
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34813223
Lelikovich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
sycoreНе то что бы оно портит жизнь, но как-то... "ненормализован" запрос чтоли.


анекдот в тему:
Заходит в кабинет к врачу мужик. И, ни слова не говоря, начинает раздеваться.
Снимает пиджак, вешает аккуратно на стул, разглаживает.
Снимает рубашку, складывает её по шовчикам, пуговки застегивает и кладет на стул.
Снимает майку тоже складывает и укладывает рядом с рубашкой.
Ботиночки рядом поставил, шнурки расправил, внутрь ботинок сложил, носки снял, по шовчикам, и на ботинки сверху уложил, правый - на правый, левый - на левый.
Брюки снял, по стрелочкам, временно на стул, снял со стула пиджак, брюки на спинку стула, пиджак поверх, снова разгладил..
Трусы снимает тоже по шовчикам разгладил, рядом с майкой положил...
Встал перед доктором.
- На что жалуетесь-то?!
- Знаете, доктор, вот посмотрите, у меня одно яичко чуть выше другого.
- Hу и что тут такого? Это нормально!
- Нуу... неаккуратно как-то...
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34813669
sycore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
>видимо это зависит от СУБД, в FireBird нельзя добавить ключ к имеющимся данным если данные в комбинации полей создаваемого ключа не уникальны

ёпрст, так приведите пример, где это не так!
По определению primary key суть unique not null, как его можно выставить, если данные будут не unique - в этом случае получится нарушение целосности системы.
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34814508
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sycore пишет:

> 1) Этому есть какое-то логическое объяснение? Ведь потенциально база
> может сделать вывод, что id - это UNIQUE и не морочить голову.

1) Запросы про constraint-ы ничего не знают и их не анализируют.
2) логическое объяснение простое - a.name непонятно из какой строки
взять. Добавление a.name в GROUP BY ничем не мешает.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34814750
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
sycore пишет:

> 1) Этому есть какое-то логическое объяснение? Ведь потенциально база
> может сделать вывод, что id - это UNIQUE и не морочить голову.

1) Запросы про constraint-ы ничего не знают и их не анализируют.
2) логическое объяснение простое - a.name непонятно из какой строки
взять. Добавление a.name в GROUP BY ничем не мешает.
Posted via ActualForum NNTP Server 1.4в конце концов - это дело оптимайзера, решать, нужно ли и по a.name что-тотам группировать, если заведомо есть not null unique в наборе, а вот если не доверяете оптимайзеру, добавте поля в набор после группировки - как подзапросы (или inner join) с a1.id = a.id (думаю это будет (иногда) даже хуже, но зато - принципиально).
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34814889
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
assa пишет:

> в конце концов - это дело оптимайзера, решать, нужно ли и по a.name
> что-тотам группировать, если заведомо есть not null unique в наборе, а

Это дело не оптимизатора, а семантики запроса. Оптимизатор здесь
ну вообще совсем ни при чем.
Даже если есть там UNIQUE CONSTRAINT, в запросе таблица с этим
констрейнтом может JOIN-иться с другими таблицами 1:N и из
какой строки брать эти значения - непонятно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34815840
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
assa пишет:

> в конце концов - это дело оптимайзера, решать, нужно ли и по a.name
> что-тотам группировать, если заведомо есть not null unique в наборе, а

Это дело не оптимизатора, а семантики запроса. Оптимизатор здесь
ну вообще совсем ни при чем.
Даже если есть там UNIQUE CONSTRAINT, в запросе таблица с этим
констрейнтом может JOIN-иться с другими таблицами 1:N и из
какой строки брать эти значения - непонятно.
Posted via ActualForum NNTP Server 1.4
1. не путайте семантику с синтаксисом.
2. если у алиаса "а" есть уникью набор, полностью фигурирующий в ГРУП бай - то только клиническому идиоту (, и некоторым непродвинутым оптимайзерам) непонятно, что группировать (запрос) надо только по ним а другие поля алиаса "а" выдавать "как есть". (напишите там какой-нито "псевдоагрегат", если субд (PostgreSQL уж точно) позволеяет их определять - никаких проблем не будет)


ЗЫ я же просто хотел тут сказать: положено перчислить все неагрегируемые поля в груп-бае - перечисляйте, а как при этом будет работать оптимайзер - это его частное дело. Если вы ему не доверяете, и точно знаете (см п.2.) как надо "считать быстро" - так и подцепляйте остальные поля уже после группировки.
...
Рейтинг: 0 / 0
Теоретический вопрос про JOIN + GROUP BY
    #34815888
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivДаже если есть там UNIQUE CONSTRAINT, в запросе таблица с этим
констрейнтом может JOIN-иться с другими таблицами 1:N и из
какой строки брать эти значения - непонятно.
Не совсем так.

Эта тема перекликается с одним понятием Oracle. В нем есть такой объект - DIMENSION, основной смысл которого можно выразить следующим образом: он подсказывает оптимизатору, что в некоторой таблице поле A определяет значения полей B, C и D (то есть - у любых строк, у который совпадает значение A, совпадают также значения B, C и D). Оптимизатор использует эту информацию при query rewrite.

Так вот: если поле A во-первых, определяет значения B, C и D, а во-вторых, участвует в группировке, это означает, что внутри любой группы B, C и D заведомо совпадают. Независимо от того, в какие join-ы вступает эта таблица.

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 5 . 0  
Connected as test

SQL> create table "unique" (id integer not null, data varchar2( 10 ));

Table created

SQL> alter table "unique" add constraint unique_pk primary key (id) deferrable initially deferred;

Table altered

SQL> insert into "unique" values ( 1 , 'first');

 1  row inserted

SQL> insert into "unique" values ( 1 , 'second');

 1  row inserted

SQL> select id, min (data), max (data) from "unique" group by id;

                                     ID MIN(DATA)  MAX(DATA)
--------------------------------------- ---------- ----------
                                       1  first      second

SQL> commit;

ORA- 02091 : transaction rolled back
ORA- 00001 : unique constraint (TEST.UNIQUE_PK) violated
...
Рейтинг: 0 / 0
16 сообщений из 16, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Теоретический вопрос про JOIN + GROUP BY
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]