5 признаков того, что ваша дальнейшая аналитика отправится в корзину
Многим из нас по «долгу службы» приходится заниматься обработкой, анализом и структурированием информации. Обычно от ТЗ до результата проходит не один запрос, а последовательность влияющих друг на друга алгоритмов и ошибка на каком-то этапе обязательно скажутся на отданном в конце проверки отчёте. Далее мы расскажем о пяти типичных (но НЕединственных) ошибках, допустив которые, вы наверняка будете краснеть перед руководителем за ваши аналитические выводы.
Приведённые ниже примеры написаны на T-SQL, но будут актуальны и на других диалектах.
1. Забыть о приоритете операторов
Имеем таблицу клиентов с их возрастом и флагом активности. Её мы будем использовать и в дальнейшем.
Нам необходимо получить всех активных клиентов в возрасте 30 или 40 лет.
Пример, уже набивший оскомину, но всё же являющийся, пожалуй, самой распространенной ошибкой новичков, да и не только. Бывало, что нет-нет да и отвлечешься на глоток чая, и попросту вылетит из головы необходимость учитывать приоритет операторов.
Написав, впопыхах, следующий скрипт:
Получим:
Явно не то, что мы хотели.
По приоритету на сайте docs.microsoft.com показана удобная таблица. В целом, всё похоже на арифметику: помни о приоритете, а если хочешь его выделить, ставь круглые скобки.
2. Неправильно применить условия при left (right и тп.) join
Предположим, мы получили такое задание:
Из таблицы п1. вывести информацию: были ли по клиентам проверки после 01.09.2019. И опираться на дополнительную таблицу проверок:
При такой трактовке задания мы держим в голове, что необходимо вывести информацию о всех клиентах, а значит можно использовать left join. При этом помним, что нужно наложить условие на дату. Но где описывать условие? Конечно, в блоке «where». Будучи уверенными в простоте и очевидности решения прописываем:
И получаем:
Так как исходных данных мало, визуально видно, что что-то не так. Однако, когда данных больше и мы пытаемся успеть к дедлайну, это может ускользнуть от взгляда. И дальнейшая аналитика уже будет базироваться на неверных данных.
Дело в том, что, прописывая условия в блоке «where» на таблицу, которую left join’им, мы нивелируем этот left join, превращая его в обычный join, а значит теряем информацию, которую хотели бы сохранить в «левой» таблице.
Корректным будет прописать условие в момент присоединения таблицы или дописать условие на NULL:
Итог:
Заметьте, по клиенту 5 проставилась информация, что проверок не было несмотря на то, что в таблице проверок по нему имеется запись. Таким образом, условие на дату наложилось корректно.
3. Забывать, что null своенравен
NULL – это особое значение и работать с ним нужно аккуратно, иначе мы рискуем потерять важные для дальнейшего анализа данные. Так как мы живём не в идеальном мире и в данных систем не всегда есть полная информация, может так случится, что некоторые поля пропущены.
Нам необходимо по клиентам вывести информацию об имеющихся продуктах (Product), но не выводить тех, у кого есть инвестиционный кредит (Subproduct).
Запрос вида:
Выдает:
Но мы потеряли клиента 2 с дебетовой картой и клиента 8 с кредитом, у которых в поле Subproduct было в силу различных обстоятельств пропущено.
Поэтому нужно перед аналитикой проработать пустые значения: понять, насколько они важны тебе в анализе, можно ли их на что-то заменить, а если нет, учитывать как особое значение:
4. Путать Union и Union ALL
Нужно помнить, что использование Union удаляет повторы в записях, а Union ALL выдает объединенные записи без дубликатов.
У нас есть две команды проверяющих, которые отмечают успешное завершение проверки по клиенту.
Нам необходимо посчитать для нашего руководителя сколько клиентов уже проверено всеми бригадами.
Результат – 2 клиента.
Несмотря на то, что первая и вторая команды проверили по 2 клиента каждая, UNION (получив оба раза по 2) просто удалил дубликаты записей, нивелировав вклад одной из команд.
Если в скрипте выше использовать Union ALL, то результат будет – 4.
Выбирая тот или иной метод объединения, нужно понимать свои данные и представлять, что мы хотим получить.
5. Не понимать between.
Используя оператор between вместо логических («>», «<», «=»), нужно помнить, что between включает в себя как начальный диапазон, так и конечный. Вроде бы всё просто, но бывает, что даже уважаемые создатели тестов по SQL, забывают про это.
Из таблицы п1:
Результат:
В данной статье были отражены некоторые ошибки, запомнить которые просто, а вот исправить уже полученные с этими ошибками результаты гораздо сложнее. Думаю, что, читая этот материал, каждый поймал себя на мысли, что хоть раз, но допускал одну из этих ошибок. Но в этом нет ничего страшного, ведь мы не роботы.
наконец-то норм статья в секции Разработка
Спасибо за вашу оценку! Нам приятно :)