Я работаю с данными уже 3 года, и меня до сих пор удивляет, что есть люди, которые хотят стать аналитиками, практически не зная SQL. Хочу особо подчеркнуть, что SQL является фундаментальным языком независимо от того, кем вы будете работать в сфере анализа данных.
Конечно, я видел исключения, когда люди, обладающие впечатляющими знаниями в других областях, помимо SQL, получают работу, но при этом после получения оффера им все равно приходится изучать SQL. Я думаю, что почти невозможно быть профессионалом в сфере анализа данных без знаний SQL.
Данные советы предназначены для всех специалистов, независимо от опыта. Я перечислил самые распространенные случаи в моей практике, разместив в порядке возрастания сложности.
Для примеров я буду использовать базу данных SQLite: sql-practice.com
1. Проверка уникальных значений в таблице
В этом примере показано, как проверить, является ли ваш столбец первичным ключом в таблице. Конечно, это обычно используется в создаваемых вами таблицах, поскольку в большинстве баз данных есть возможность указать первичный ключ в метаданных информационной схемы.
Если числа из двух столбцов равны, то столбец, который вы подсчитали во второй части запроса, может быть первичным ключом. Это не всегда является гарантией, но иногда может помочь разобраться.
Однако становится немного сложнее, когда у вас есть несколько столбцов, которые создают первичный ключ. Чтобы решить эту проблему, просто объедините столбцы, составляющие первичный ключ, после ключевого слова DISTINCT
. Простой пример — объединение имени и фамилии для создания первичного ключа.
2. Поиск повторяющихся записей
Таблица из примера — это упрощенная версия баз данных, которые вы будете использовать в своей работе. В большинстве случаев вы захотите выяснить причины дублирования значений в базе данных. Для этого вам пригодится данный запрос.
Вы можете использовать ключевое слово HAVING
для сортировки повторяющихся значений. В таком случае вы заметите, что чаще всего дублируется имя Джон
. Затем вы запустите еще один запрос, чтобы увидеть причину повторяющихся значений, и увидите, что все пациенты имеют разные фамилии и ID
.
3. Обработка NULL с DISTINCT
Результатом запроса будет значение 4531
для столбца COUNT(*)
и 4530
для двух оставшихся столбцов. Когда вы указываете столбец, ключевое слово COUNT
исключает нулевые значения. Однако, при использовании звездочки в подсчет включаются значения NULL
. Это может сбивать с толку при проверке, является ли столбец первичным ключом, поэтому я посчитал нужным упомянуть об этом.
4. CTE > Подзапросы
Когда я впервые начал работать аналитиком данных 3 года назад, я писал SQL-запросы с большим количеством подзапросов, чем это было необходимо. Я быстро понял, что это не приводит к читабельному коду. В большинстве ситуаций вы хотите использовать общее табличное выражение вместо подзапроса. Зарезервируйте подзапросы для однострочников, которые вы хотите использовать.
5. Использование SUM и CASE WHEN вместе
Предложение WHERE
может работать, если вы хотите суммировать количество пациентов, отвечающих определенным условиям. Но если вы хотите проверить несколько условий, вы можете использовать ключевые слова SUM
и CASE WHEN
вместе. Это делает код лаконичным и легко читаемым.
Данную комбинацию также можно использовать в выражении WHERE
, как в примере ниже.
6. Будьте осторожны с датами
В этой базе данных все даты сокращены до дня. Это означает, что все значения времени столбца Birthday_date
в этом примере равны 00:00:00
. Однако в реальных наборах данных это обычно не так.
В зависимости от среды разработки SQL ваши настройки могут скрыть отображение времени. Но то, что время скрыто, не означает, что оно не является частью данных.
В приведенном выше примере я искусственно добавил секунду к пациенту №1
. Как видите, этой 1-й секунды было достаточно, чтобы исключить пациента из результатов при использовании ключевого слова BETWEEN
.
Еще один распространенный пример, который чаще всего упускают из вида специалисты по работе с данными, — это присоединение к датам, в которых все еще есть временной компонент. В большинстве случаев они действительно пытаются присоединиться к столбцам с сокращенной датой и, в конечном итоге, не получают желаемого результата или, что еще хуже, они не осознают, что получили неправильный результат.
7. Не забывайте об оконных функциях
Оконные функции — отличный способ сохранить все строки данных, а затем добавить еще один столбец с важными агрегатными сведениями. В этом случае мы смогли сохранить все данные и добавить максимальный вес по столбцу города.
Я видел, как некоторые аналитики пробовали обходные пути, когда оконная функция делала код короче и читабельнее и, скорее всего, также экономила им время.
Существует множество различных оконных функций, но приведенный выше пример является распространенным и простым вариантом использования.
8. По возможности избегайте DISTINCT
Последние 3 совета не содержат примеров программного кода, но они так же важны, как и приведенные выше. По моему опыту, специалисты по работе с данными слишком часто используют distinct
, чтобы предотвратить дублирование, не разбираясь в причине.
Это ошибка. Если вы не можете с самого начала объяснить, почему в данных есть дубликаты, возможно, вы исключили из своего анализа какую-то полезную информацию. Вы всегда должны быть в состоянии объяснить, почему вы помещаете distinct
в таблицу и почему есть дубликаты. Использование WHERE
обычно предпочтительнее, так как вы можете увидеть то, что исключается.
9. Форматирование SQL
Об этом сказано довольно много, но стоит повторить. Обязательно отформатируйте SQL. Лучше создать больше строк с хорошим форматированием, чем пытаться сжать весь код всего в несколько строк. Это позволит ускорить разработку.
Вы можете заметить, что в примерах я использовал TRUE
в WHERE
выражении. Это было сделано для того, чтобы все аргументы в выражении WHERE
начинались с AND
. Таким образом, аргументы начинаются с одного и того же места.
Еще один быстрый совет — добавить запятые в начале столбца в выражении SELECT
. Это позволяет легко найти пропущенные запятые, поскольку все они будут упорядочены.
10. Совет по отладке
Некоторые SQL-запросы могут быть очень сложными для отладки. Что мне больше всего помогло, когда я сталкивался с этим в прошлом, так это то, что я очень усердно документировал свои шаги.
Чтобы задокументировать шаги, я пронумерую часть кода в комментариях перед запросом. Комментарий описывает, что я пытаюсь сделать в этом разделе запроса. Затем я напишу свой ответ под заголовком комментария после выполнения запроса.
Во время отладки действительно легко увидеть варианты, которые вы уже попробовали, и я обещаю, что с таким подходом вы решите эту проблему быстрее.
Надеюсь, вы узнали что-то полезное из приведенных выше советов. Какие из них вы нашли наиболее полезными? Мы также с нетерпением ждем ваших советов и, пожалуйста, дайте ссылки на любые другие полезные статьи в комментариях, спасибо!
Материалы по теме
- 📜 Основные SQL-команды и запросы с примерами, которые должен знать каждый разработчик
- 🐘 Руководство по SQL для начинающих. Часть 1: создание базы данных, таблиц и установка связей между таблицами
- 🐘 Руководство по SQL для начинающих. Часть 2: фильтрация данных, запрос внутри запроса, работа с массивами
- 🐘 Руководство по SQL для начинающих. Часть 3: усложняем запросы, именуем вложенные запросы, анализируем скорость запроса
Комментарии