Как стать автором
Обновить

Комментарии 7

Как говорили в детстве на футболе, «разбег на рубль, удар на копейку». Одна простенькая задача, кмк не очень специфичная для Data Science, которую легко решит большинство программистов, имевших дело с базами данных. Зато очень многообещающий заголовок.
Задачка действительно простенькая, но для меня статья не совсем уж бесполезная, или даже совсем не бесполезная. Ссылочка на ресурс stratascratch.com для меня оказалась новой и интересной — как оказалось, там можно потренироваться, размяться немного в навыках составления SQL-запросов и, вроде, там же есть упражнения на python, но туда я не заглядывал.
когда больше уже не о чем написать, но план по написанию статей есть
Прочитал — и обалдел…

Вот как соотносятся эти две цитаты?
inspection_date — datetime
и
столбец inspection_date, на самом деле, хранит не дату. Это — объект, который, в соответствии с особенностями платформы, хранит либо текстовые данные, либо данные типа varchar.

В подавляющем большинстве СУБД DATETIME — это тип данных, который хранится в упакованном бинарном виде (из распространённых, пожалуй, только SQLite выделилась в этом вопросе). Текст — это представление даты при отдаче результата запроса «наружу» (и на это преобразование сервер потратит определённые ресурсы — человеки, увы, не умеют читать дату в бинарном виде).

К слову, а какая разница в данном контексте между «текстовыми данными» и VARCHAR?

И пошло-поехало — CAST в дату, экстракция года… а ведь на финише ещё и преобразование в текстовое представление (по уже описанной причине). А не проще сразу перегнать в текст, строковой функцией откусить из нужного места 4 символа (или сразу задать формат «только год» при преобразовании в строку, если есть такая функция), и по полученному значению группировать?

И последнее. Задание просило
Выведите количество таких проверок с группировкой по годам в нисходящем порядке.
Так вот, согласно правилам русского языка «в нисходящем порядке» — это не про годы, а про количество проверок. Так что увы-увы…

И совсем последнее. Прямо под наименованием статьи есть гиперлинк с текстом «Автор оригинала: Rakib Raihan». Увы, ведущий в никуда… «We can't find the page you're looking for.»
Допустимо, кроме того, поместить YEAR в выражение GROUP BY, так как выражение SELECT выполняется первым. В результате интерпретатору, после выполнения этого выражения, уже будет известно о том, что в запросе имеется столбец с именем YEAR:

Вообще, интересно — это часть стандарта или нет? Для MS SQL Server — это процитированное утверждение ложно, обращаться к столбцу по псевдониму в GROUP BY в нём нельзя. SQL Bolt и Towads Data Science, без привязки к СУБД, тоже говорят о том, что GROUP BY «выполняется до» SELECT. А PostgreSQL позволяет такое, MySQL, видимо тоже.
приятно работать с текстовой датой, year=substr (date, 1, 4)
но боже мой, с датами столько всяких плясок бывает — юникс таймстемп, исо8601, временные зоны и их преобразования… и все это во всех диалектах по разному… так что тема не раскрыта
EXTRACT (YEAR FROM cast(inspection_date as DATE)) = 2015 — так в принципе не получится использовать индекс по inspection_date.

Если inspection_date имеет тип DATE, то существенно эффективней было бы сделать индекс по inspection_date и использовать выражение вида inspection_date BETWEEN CAST ('2015-01-01' AS DATE) AND CAST ('2015-12-31' AS DATE)
Со строкой аналогично но уже в виде inspection_date>='2015' AND inspection_date<'2016'

Что касается Data Science, тут даты индексируются в подавляющем большинстве случаев. Потому как на входе миллиарды записей.

Так же, настоятельно не рекомендую подстраивать платформу под инструмент (Python), вместо того, чтобы подстраивать инструменты под платформу и цели. Это уже отчетливо пахнет «золотым молотком». Существенно эффективней хранить данные в оптимальном формате для БД, а не для одного из используемых инструментов. Тогда, по необходимости, и инструменты можно менять аки перчатки.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий