Трансляция чата "SQLize.online"

[Forum Publisher]

https://t.me/sqlize/26576

Где можно почитать о том, почему не стоит использовать using?

И в чем проблема с джойнами?
Моя идея была в том, что мы для корректного расчета среднего хотим оставить все записи в таблице rental. Уберем оттуда все фильмы что не вернули, убрав строчки с пустыми полями.

А min в order - глупость, видимо уже не соображал что делал.
И спасибо за ответы и обратную связь

[Forum Publisher]

https://t.me/sqlize/26577

ну я выше написал же, почитай

[Forum Publisher]

https://t.me/sqlize/26578

join должны быть не left, а inner, ты эти данные непосредственно в запросе обрабатываешь, и кроме этого не может быть запись в rental без записи в inventory и film, следствие целостности базы данных которые обеспечиваются внешними ключами да и просто логикой

[Forum Publisher]

https://t.me/sqlize/26579

Ещё раз using поддерживают не все СУБД и когда ты их пишешь часть работы по оформлению запроса берёт на себя СУБД, а задача этого сайта в частности чтобы обучать тебя писать запросы , а не СУБД в этом тренировать

[Forum Publisher]

https://t.me/sqlize/26582

Илья, я снова Вам возражу.
С одной стороны, Вы справедливо заметили, что ресурс учебный, т.е. позволяет на практике ознакомиться с SQL. Но это предполагает ознакомление со всеми синтаксическими конструкциями, и с этой точки зрения повода исключать USING нет, это часть стандарта.
С другой стороны, Вы апеллируете к идее универсальности SQL. Однако на ресурсе представлены несколько СУБД, каждая со своим списком отклонений от ANSI SQL. И если поставить во главу угла написание кода, переносимого хотя бы в рамках этих 5 СУБД, то многие задачи станут просто неразрешимы - не все СУБД умеют в аналитику, у каждой свой подход к date arithmetic... список различий на самом деле достаточно длинный чтобы отбросить эту идею в пользу другой, гораздо более богатой с точки зрения обучения - у каждой СУБД есть свои сильные стороны и, хотя написание специализированного кода требует ознакомления с документацией на целевую СУЬД, не использовать эти возможности просто контрпродуктивно.
Исходя из изложенного я полагаю Ваш совет отказаться от той или иной конструкции из соображений совместимости неверным и даже вредным, особенно если конструкция входит в ANSI SQL.

[Forum Publisher]

https://t.me/sqlize/26583

Всем привет, может кто то мне сможет объяснить. Вероятно, я не понимаю условие или еще что-то.
Задача: https://sqltest.online/ru/question/sql- ... each-other

Если я правильно понял, то считается что клиенты встречались, если у них rental_date и staff_id равны.

В правильном ответе пишет, что должно быть 25 строк, но как это возможно, если есть запись

Код: Выделить всё

select * from rental where rental_date = '2006-02-14 15:16:03' and staff_id = 1

которая выдает 85 разных клиентских id, т.е. каждый из них встречался с другим в этот день, что уже явно дает более 25 возможных пар.


Либо я что-то в задании не так понимаю, либо не на те даты смотрю.
Буду признателен за пояснение.

[Forum Publisher]

https://t.me/sqlize/26584

Неверно. Надо найти клиентов, которые пересекались по времени в одном месте (store), а не обслуживались одним сотрудником (staff).

[Forum Publisher]

https://t.me/sqlize/26585

так по staff_id я узнаю store_id это же будет одно и тоже место. Врядли один сотрудник мог одновременно выдавать диски в двух филиалах?

[Forum Publisher]

https://t.me/sqlize/26586

Проверьте своё предположение. Искать и находить data inconsistency - важный скилл аналитика данных и очень полезный для разработчика.

[Forum Publisher]

https://t.me/sqlize/26587

ок, спасибо