Не он один

шо, и MSSQL не понимает?

Нет просто на оракле не пишут те дебилы, которые не могут уяснить простое правило: либо под агрегатом, либо в group by

Фига ты тут скока народу дебилами обозвал

шо, и MSSQL не понимает?

95% СУБД не дают это делать

Фига ты тут скока народу дебилами обозвал

Мускульщиков?

хотя я вот от ораклоидов часто слышу байку про "НАДО ВСЕГДА УКАЗЫВАТЬ". я так понимаю, Oracle функциональные зависимости вообще не понимает?

несомненно, любопытная фича, и - да, в оракле такое не сработает, однако, и минус налицо - поглядев на код совершенно не понятно - он написан криворуким дебилом или там в таблицах есть "функциональные зависимости" и разработчик их учел

Мускульщиков?

и примкнувших к ним постгресистов!

но это неверно, начиная с SQL:99

Смотрю на него, нет тут такого

Не надо специфику одной (не лучшей БД) применять на весь стандарт

Смотрю на него, нет тут такого

по второй ссылке есть указатель на стандарт. это "optional behavior" начиная с SQL:99

по второй ссылке есть указатель на стандарт. это "optional behavior" начиная с SQL:99

вторая ссылка - это "не лучшая БД"

@SLASH_CyberPunk А есть лучшая в принципе?

Расскажи))))

@SLASH_CyberPunk А есть лучшая в принципе?

нет, есть худшая

Субъективненько

@SLASH_CyberPunk А есть лучшая в принципе?

несомненно!

Причём ООООООЧЕНЬ

Oracle Compliance To Core SQL:2008 https://docs.oracle.com/cd/E11882_01/server.112/e41084/ap_standard_sql003.htm#r5c1-t2 щас поглядим, что там есть в E051, потому что тут не написано, что именно не поддерживается

Субъективненько

от части

несомненно, любопытная фича, и - да, в оракле такое не сработает, однако, и минус налицо - поглядев на код совершенно не понятно - он написан криворуким дебилом или там в таблицах есть "функциональные зависимости" и разработчик их учел

но у этой фичи есть вполне себе валидные области применения. действительно есть схемы и запросы, где перечислять всё на свете в GROUP BY — излишество. и оптимизитору не повредит быть достаточно умным, чтобы такие вещи определять

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

но у этой фичи есть вполне себе валидные области применения. действительно есть схемы и запросы, где перечислять всё на свете в GROUP BY — излишество. и оптимизитору не повредит быть достаточно умным, чтобы такие вещи определять

это не умаляет важности читабельного кода

Просто потому что "так надо"?

Чем-то попахивает на "наши предки так делали, и ты делай, традиция же"

А читабельности агрегат по справочному значению вряд ли прибавит. Наоборот, сразу видно, что тут всё норм

это не умаляет важности читабельного кода

а с читабельностью всё просто — "неправильные" запросы с GROUP BY просто не будут выполнятся. по крайней мере в mysql и postgresql

но у этой фичи есть вполне себе валидные области применения. действительно есть схемы и запросы, где перечислять всё на свете в GROUP BY — излишество. и оптимизитору не повредит быть достаточно умным, чтобы такие вещи определять

есть оптимизатор, который позволет просто номер колонки указывать - такое есть

но postgresql туповат в этом плане. он функциональные зависимости только в пределах одной таблицы умел определять. а с джойнами там была беда, по крайней мере в 9.6. более поздние не тестировал

а с читабельностью всё просто — "неправильные" запросы с GROUP BY просто не будут выполнятся. по крайней мере в mysql и postgresql

я про code review глазом, а не компилятором.

Не надо специфику одной (не лучшей БД) применять на весь стандарт

Да к чему этот пустой трёп вообще? Парень спросил, что у него не так. Ему был дан нужный совет. Парень довольный, отвалил. Всё.

ну тут же чятик

но postgresql туповат в этом плане. он функциональные зависимости только в пределах одной таблицы умел определять. а с джойнами там была беда, по крайней мере в 9.6. более поздние не тестировал

Функциональные зависимости даже теоретически в РСУБД в рамках БД не описываются никак. Нет средств.

я про code review глазом, а не компилятором.

я себе плохо представляю code review запросов в отрыве от схемы. это какой-то очень специальный code review

я себе плохо представляю code review запросов в отрыве от схемы. это какой-то очень специальный code review

простите, а вы чем занимаетесь?

наверно аппликейшены пишите в орме?

Да неважно, но постановка вопроса действительно странная. Очевидно же, что ревьюер должен разбираться в схеме.

Функциональные зависимости даже теоретически в РСУБД в рамках БД не описываются никак. Нет средств.

primary/unique key — вполне себе функциональные зависимости. джойны по таким полям тоже.

вот вообще не показатель

да ясен красен

тем более, мне прям стало интересно, как вы по PK найдете все зависимости?

для этих целей есть констрейты

вот только их использование - это редкость

ну там же по ссылочкам примеры, прямо вот в картинках, не?

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

вот же bombanoolo то

primary/unique key — вполне себе функциональные зависимости. джойны по таким полям тоже.

От чего?

вот же bombanoolo то

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

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

погодите, там же FK объявлены (я о первой ссылке про film_actor)

погодите, там же FK объявлены (я о первой ссылке про film_actor)

окей, список мне по FK

без констрейтов БД не знает ничего

для этих целей есть констрейты

Нет таких констрейнтов, которые бы ФЗ описывали...

ФЗ?

функциональную зависимость

ФУНКЦИОНАЛЬНАЯ ЗАВИСИМОСТЬ

а PK -> row — это же именно оно?

а PK -> row — это же именно оно?

Увы, нет

здрасьте приехали

тогда я запутался %)

совокупность PK-FK и констрейта как раз целиком описывает

а PK -> row — это же именно оно?

Это было бы именно оно, если бы таблица находилась в 3-5 НФ.

без констрейта вот как раз не описывается

А находится оно или нет — не знает никто, кроме проектировщика БД.

Так что не трахайте мне и себе мозги, и пишите GROUP BY. На этом всё.

ну как бы да, стандарт говорит писать все

все строки таблицы функционально зависимы от PK/UK, просто по определению. хватит пургу нести

Да неважно, но постановка вопроса действительно странная. Очевидно же, что ревьюер должен разбираться в схеме.

именно, но если сейчас такой запрос в коммите от джуниора явно говорит об ошибке/опечатке, то в случае нечетких условий постановки group by потребует уже явно перепроверять еще и схему (которую в серьезных разработках и архитектор наизусть не помнит, естественно), тратится лишнее время

ERROR: S client not available

все строки таблицы функционально зависимы от PK/UK, просто по определению. хватит пургу нести

ЭТо ты путаешь причину и следствие. Они В ТЕОРИИ должны быть зависимы. Да. А вот на практике они зависимы или нет — да хрен их знает...

оооокей

именно, но если сейчас такой запрос в коммите от джуниора явно говорит об ошибке/опечатке, то в случае нечетких условий постановки group by потребует уже явно перепроверять еще и схему (которую в серьезных разработках и архитектор наизусть не помнит, естественно), тратится лишнее время

С этим, пожалуй, соглашусь. «Принцип наименьшего удивления»

все строки таблицы функционально зависимы от PK/UK, просто по определению. хватит пургу нести

Представь себе самый распростанённый случай — PK в виде SERIAL/IDENTITY. Т.е. идентификатор строки в таблице. И расскажи пожалуйста, ЧТО ЖЕ ОТ НЕГО БУДЕТ ФУНКЦИОНАЛЬНО ЗАВИСИТЬ?

Представь себе самый распростанённый случай — PK в виде SERIAL/IDENTITY. Т.е. идентификатор строки в таблице. И расскажи пожалуйста, ЧТО ЖЕ ОТ НЕГО БУДЕТ ФУНКЦИОНАЛЬНО ЗАВИСИТЬ?

Да нифига не будет.

Однозначно — все остальные (неключевые) поля строки.

@alexey_kopytov Ты короче ничего не понимаешь в системах, в разработке которых сам же и учавствовал?

да вообще беда :)

Так мы договоримся до того, что наличие ключей вообще является слишком сильным условием, и лучше бы на это в размышлениях не полагаться ;)

Однозначно — все остальные (неключевые) поля строки.

С какого? ФЗ определяется в рамках предметной области. PK в виде INENTITY очевидно в рамках предметной области не значит вообще ничего.

@alexey_kopytov Ты короче ничего не понимаешь в системах, в разработке которых сам же и учавствовал?

а что там разрабатывал он, поподробнее можно?

а то я часто вижу непонимание разработчиков ?

С какого? ФЗ определяется в рамках предметной области. PK в виде INENTITY очевидно в рамках предметной области не значит вообще ничего.

Вообще это хороший вопрос. А действительно ли для определения наличия/отсутствия ФЗ нужно подниматься до семантики предметной области (читай: включать голову)? Или всё-таки мы можем сделать такой вывод на основании имеющихся данных?

Вообще это хороший вопрос. А действительно ли для определения наличия/отсутствия ФЗ нужно подниматься до семантики предметной области (читай: включать голову)? Или всё-таки мы можем сделать такой вывод на основании имеющихся данных?

ну вот оптимизатор-то как-то справляется, значит, в тех СУБД, где эта фича с group by работает.

Вообще это хороший вопрос. А действительно ли для определения наличия/отсутствия ФЗ нужно подниматься до семантики предметной области (читай: включать голову)? Или всё-таки мы можем сделать такой вывод на основании имеющихся данных?

Ещё раз, всё наоборот. ФЗ определяется в предметной области, на её основе проектируется БД, и затем уже мы СПУСКАЕМСЯ до уровня РБД и РСУБД.

ну вот оптимизатор-то как-то справляется, значит, в тех СУБД, где эта фича с group by работает.

Где эта фича (возможность частично НЕ УКАЗЫВАТЬ НЕАГРЕГИРУЕМЫЕ ПОЛЯ В GROUP BY) сервер просто выдаёт (может выдавать) любые левые данные в результирующем запросе, а ты их потом МОЛЧА хаваешь...

обычно кто такое пишет - знает об этом

а для остальных есть only full group by

А если я не хочу напрягать сервак аггрегацией заранее известных данных?

Ещё раз, всё наоборот. ФЗ определяется в предметной области, на её основе проектируется БД, и затем уже мы СПУСКАЕМСЯ до уровня РБД и РСУБД.

Я бы сначала вообще построил модель работы. А потом уже переходил к проектированию бд

А то возможны всякие нежданчики

А если я не хочу напрягать сервак аггрегацией заранее известных данных?

Ну тогда не напрягай. Получишь в ответе все как попало.

Обычно оно и не имеет смысла проводить групировку

Только если тебе нужно это потом каким то замысловатым образом обрабатывать или выводить

Group by это по сути сортировка

И при больших объемах запроса может отьедать кучу времени

Вопрос. Если я опишу структуру файла для обработки. И можно будет их закидывать через бота в телеге. Типа подготовишь сет и зашлешь. Потом тесты/задания шлешь и получаешь ответы. Такой бот-аналитик. Кому нибудь интересно?

Вопрос. Если я опишу структуру файла для обработки. И можно будет их закидывать через бота в телеге. Типа подготовишь сет и зашлешь. Потом тесты/задания шлешь и получаешь ответы. Такой бот-аналитик. Кому нибудь интересно?

На какую тему?

На какую тему?

На любую. Исключая фото/видео.

Хм. Если я начну логи из системы мониторинга слать - чему он обучится?

Хм. Если я начну логи из системы мониторинга слать - чему он обучится?

Тому на что ты ему укажешь. Ты же знаешь как происходит обучение.

Давай его просто в какую-нибудь флудильню добавим