Комментарии 8
В примере 3 представьте, что клиентов трое, выручка с каждого — 10000.
"Аналитик ставит задачу data инженеру". Этот ваш инженер - это и есть аналитик, просто вы его не цените, ограничиваете его творческий потенциал, спрашиваете глупые вопросы и мешаете нормально связать разные источники данных. Он дал правильный ответ и решённую задачу в долгосрочной перспективе, но вы не хотите. Этот товарищ, который фантазирует, что его убивает начальник, зря получает зп ;-)
Примеры запросов неплохие. С запятыми - не ошибка, ошибка не использовать настроенное автоматическое форматирование в конце. Не связывать данные и реальность - не ошибка, это способность.
Но ведь запятые в конце строки не являются ошибкой (хоть сам я и ставлю их в начале).
С запятыми в конце запрос ломается, если закомментировать последнюю строчку, но с запятыми в начале то же самое произойдет, если закомментировать первую строчку.
Поэтому перед написанием SQL запроса стоит выяснить, какая СУБД используется.
Мало. Нужна ещё точная версия. Старая версия на проде запросто может не поддерживать свежие возможности, реализованные в домашней версии, например.
Если писать код с запятой в начале строки, это поможет копировать, вставлять, удалять и добавлять поля без ошибок. Код будет визуально длиннее, но его читаемость возрастет. И не нужно будет тратить время на отслеживание запятых.
А потом аналитик вставит поля в начало списка вывода, и получит те же грабли, но вид спереди.
И насчёт возросшей читаемости - я совершенно не согласен. Выравнивание отступов гораздо важнее.
Data инженер со своей стороны может попробовать изменить тип данных столбца order_sum на более подходящий. Тогда в будущем похожих проблем не возникнет.
Приведение суммы вычисленных значений к заданному значению после округления - весьма нетривиальная задача. И простое изменение типа данных неспособно её решить в принципе. Так что проблемы обязательно возникнут.
Код: выбрать не одного клиента, а всех, у кого сумма заказа максимальна
Подзапрос в Postgre, который прекрасно поддерживает CTE и аналитические функции? Серьёзно?
Могут ли быть одинаковые имена клиентов? Да. А почтовые адреса? Нет.
Да кто Вам такое сказал? Сплошь и рядом... полтораста ИП на одном адресе - самая что ни на есть реальная реальность. Ну и даже элементарно отец и сын, оба Иван Иванычи...
Например, результат некорректного запроса с процентами проверим так
Проверять надо именно данные, требующие проверки. Отдельный запрос проверяет только самого себя. Для Postgre - надо проверяемый запрос превратить во VIEW либо в CTE, и на основании этой конструкции проверить сумму. Именно сумму данных, отдаваемых запросом.
Ну и опять - подзапрос.
И с округлением какая-то фигня. Если мы округляем до целых, но в разряде целых единиц мы никогда не получим истину.
99.5% + 0.5% => 100% + 1% => 101%
Сам в недавнем времени начал изучать SQL — переезжаем с PowerBI на Apache Superset. Работаю в паре с дата-инженером, который ревьюит мои запросы.
Поделюсь двумя вещами, которые вывели меня на новый уровень: код проще писать в DataGrip, ибо он подсвечивает синтаксис и выводит таблицу с результатами запроса без этих ваших /*проверяем сумму процентов*/ select sum(precent_of_revenue) from percent_revenue
Второе — есть чудесный инструмент HAVING, который помогает отфильтровать результат не только по значениям в полях, но и по сложным условиям (например вместо подзапроса)
?
Sore query language, или 5 ошибок при первом изучении SQL