VelStyling

VelStyling

Аналитик с 12-летним стажем. Внедрение систем подкласса MDM. А с недавних пор "уставший" аналитик данных, желающий вновь влюбиться в свою деятельность.
Пикабушница
115 рейтинг 18 подписчиков 0 подписок 30 постов 0 в горячем
1

AND и OR в SQL: как правильно соединять условия

Когда мы работаем с базой данных, почти всегда хотим не просто что-то выбрать, а применить несколько условий сразу. Например: выбрать всех клиентов старше 18 лет и с активной подпиской.

И здесь на помощь приходят два основных логических оператора: AND и OR.

AND и OR в SQL: как правильно соединять условия Аналитика, Эмоциональное выгорание, Аналитик, Системный аналитик, SQL, Microsoft Excel, Таблица, Данные, База данных, IT

Что делают AND и OR

  • AND — «и». Все условия должны быть выполнены одновременно.
    Пример: выбрать из холодильника молоко и яйца, чтобы приготовить омлет:

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

(Да, в реальности одной строки с молоком и яйцом не будет, но идея ясна: оба условия должны выполняться вместе.)

OR — «или». Достаточно, чтобы выполнено было хотя бы одно условие.
Пример: выбрать продукты, которые нужно купить или молоко, или яйца:

SELECT *

FROM shopping_list

WHERE product = 'milk' OR product = 'eggs';

Где могут использоваться

Эти операторы обычно используют в блоке WHERE, чтобы фильтровать данные.
Также можно применять их в:

  • HAVING — фильтрация агрегатов после GROUP BY

  • JOIN ON — комбинирование условий соединения таблиц

Пример с HAVING:

SELECT category, COUNT(*)

FROM fridge

GROUP BY category

HAVING COUNT(*) > 5 AND AVG(expiry_date) < '2025-08-01';

Особенности и нюансы:

  • Порядок выполнения важен

    AND имеет более высокий приоритет, чем OR.

    Если смешиваете их, всегда используйте скобки для точного порядка:

    SELECT *

    FROM fridge

    WHERE (product = 'milk' OR product = 'eggs') AND expiry_date < '2025-08-01';

  • AND «сжимает» результат, OR «расширяет» результат

    AND оставляет меньше строк, OR — больше

Частые ошибки

  • Забыли скобки и получили слишком большой или слишком маленький результат

  • Использовали AND там, где нужен OR (или наоборот)

  • Смешали NULL значения: NULL AND TRUE и NULL OR TRUE могут вести себя неожиданно

Представим, что мама проверяет холодильник:

  • У неё есть список продуктов, которые могут испортиться: молоко, яйца, йогурт

  • Она хочет приготовить что-то, если и молоко, и яйца в наличии → AND

  • Она хочет перекусить, если есть молоко или йогурт → OR

В SQL это выглядит так:

-- Для приготовления омлета

SELECT *

FROM fridge

WHERE product = 'milk' AND product = 'eggs';

-- Для перекуса

SELECT *

FROM fridge

WHERE product = 'milk' OR product = 'yogurt';

AND и OR — это простые, но мощные инструменты фильтрации. Правильное использование скобок и понимание приоритета операторов помогает избежать ошибок и выбирать точно те данные, которые нужны.

А в своем канале На связи: SQL я публикую информацию с особенностями и нюансами в языке SQL, разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Показать полностью
7

WHERE в SQL: как домохозяйка наводит порядок в холодильнике

Каждый из нас ежедневно сталкивается с бытовыми вопросами. У вас огромный холодильник: продукты, напитки, соусы, остатки вчерашнего ужина. Каждый день нужно понять: что из этого пригодно к употреблению сегодня, что нужно использовать для обеда, а что отправить в мусор.

WHERE в SQL: как домохозяйка наводит порядок в холодильнике Аналитика, Эмоциональное выгорание, Услуги, SQL, Microsoft Excel, Аналитик, Данные, База данных, Запросы, IT, Смена профессии, Длиннопост

Вот тут и появляется WHERE. Это фильтр, который помогает выбрать именно нужные строки из таблицы — или продукты из холодильника.

А в своем канале На связи: SQL я публикую информацию с особенностями и нюансами в языке SQL, разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Нам нужно выкинуть все продукты, у которых истек срок годности:

SELECT *
FROM fridge
WHERE expiry_date < CURRENT_DATE;

fridge — наша таблица с продуктами
expiry_date < CURRENT_DATE — условие: выбираем просроченные продукты
CURRENT_DATE - текущая дата

Что можно писать в WHERE

  • Сравнения: =, >, <, >=, <=

  • Логические связки: AND, OR, NOT

  • Проверки на вхождение: IN, BETWEEN, LIKE

  • Подзапросы: «проверить список покупок перед выбором»

Или, мы хотим приготовить что-то на десерт:

SELECT *
FROM fridge
WHERE category = 'dessert' AND expiry_date > CURRENT_DATE;

Условие AND expiry_date > CURRENT_DATE добавляем на случай, если мы не выкинули всю просрочку до этого.

Подзапросы

В WHERE можно использовать подзапросы. Это когда нам нужна информация из другого источника, чтобы использовать ее в своем запросе. Например, нам надо понять что из рецепта отсутствует у нас в холодильнике.

SELECT *
FROM cooking_recipe
WHERE product NOT IN (SELECT product FROM fridge);

WHERE проверяет какие продукты отсутствуют в холодильнике.

Аналогично можно использовать EXISTS или NOT EXISTS
SELECT *
FROM fridge f
WHERE EXISTS (SELECT 1 FROM cooking_recipe s WHERE s.product = f.product);

EXISTS = есть продукт в списке
NOT EXISTS = нет продукта в списке

ANY \ ALL

Эти конструкции позволяют сравнивать с набором значений.

SELECT *
FROM fridge
WHERE expiry_date <= ALL (SELECT expiry_date FROM fridge WHERE category = 'milk');

Все хорошие домохозяйки используют принцип ротации. Выбирают продукты, срок годности которых меньше всех в категории “молоко”.

  • Подзапрос (SELECT expiry_date FROM fridge WHERE category = 'milk') возвращает даты всех банок молока.

  • Условие expiry_date <= ALL (...) означает: выбрать только те банки, у которых дата годности меньше или равна каждой другой банке молока.

  • Практически это банка (или несколько, если даты совпадают), которая старше всех остальных.

То есть, результат будет одна или несколько банок с самой ранней датой годности.

SELECT *
FROM fridge
WHERE expiry_date <= ANY (SELECT expiry_date FROM fridge WHERE category = 'milk');

  • Условие expiry_date <= ANY (...) означает: выбрать все банки молока, у которых дата годности меньше или равна хотя бы одной другой банке молока.

  • Тут почти все банки проходят условие, кроме самой свежей (если она самая большая по сроку).

  • Результат может быть несколько банок, не обязательно только одна. Все, кто «моложе или равны хотя бы одной другой», будут выбраны.

CASE в WHERE

Можно использовать CASE для сложной логики

SELECT *
FROM fridge
WHERE
CASE
WHEN product = 'milk' THEN shelf = 'top'
ELSE shelf = 'middle'
END;

Если я ищу молочные продукты в холодильнике, то должна их искать на самой верхней полке, иначе - на средней.


Ну а если тебе нужны слова поддержки и мотивации, то заглядывай в канал Сила слов. Там каждое утро приходит мотивационное сообщение для тебя, чтобы ты верил себе и в себя, продолжал или только начинал действовать.

Показать полностью

Структура запроса SQL и порядок выполнения блоков

Многие думают, что SQL читается сверху вниз — как написано, так и выполняется. Но это не так.
SQL-запрос устроен хитро: порядок написания порядок выполнения.

Структура запроса SQL и порядок выполнения блоков Microsoft Excel, Аналитика, Эмоциональное выгорание, SQL, Аналитик, База данных, Самообразование, Профессия, Онлайн-курсы, Бесплатное обучение, Поиск работы, Курсы

Классический скелет запроса выглядит так:

SELECT — какие поля выбрать

FROM — из какой таблицы

JOIN — если нужно соединение

WHERE — фильтрация строк до агрегации

GROUP BY — группировка

HAVING — фильтрация групп (после агрегации)

ORDER BY — сортировка

LIMIT — ограничение количества строк

SELECT — это конструктор. Ты как будто сначала берёшь детали, потом отбираешь нужные, потом собираешь по группам, и только потом смотришь итог.

Мы привыкли, что текст читается слева направо, сверху вниз. Но не везде так:

  • в арабском и иврите — читают справа налево,

  • в китайском — традиционно писали сверху вниз.

Это не ошибка, не странность, а особенность языка, которая исторически так сложилась.

SQL — тоже «язык», и у него есть свои правила: мы пишем запрос сверху вниз, начиная с SELECT
А выполняется сам запрос совсем в другом порядке.

Об этом уже есть пост в моем новом канале На связи: SQL. Это канал про нюансы SQL, практические задачки и многое другое, что связано с аналитикой. Его я создала недавно абсолютно с нуля. Так что, если интересно, то подписывайся. А вот и ссылка на пост про последовательность выполнения запросов.

Где ещё встречается разница между тем, как пишут и как «читают»:

  • Музыка 🎼
    В нотах всё аккуратно записано: сверху вниз, слева направо. Но музыкант, читая ноты, должен сначала понять тональность, размер, темп, и только потом играть каждую ноту по порядку. То есть фактически исполняется не в том же порядке, как просто «прочитал глазами».

  • Рецепты в кулинарии 👩‍🍳
    В рецепте шаги написаны линейно: 1, 2, 3. Но когда готовишь, иногда сначала ставишь воду кипятиться, пока режешь овощи. Т.е. порядок написанного ≠ фактический порядок действий.

  • Юридические документы 📑
    Контракт читается сверху вниз, но при толковании юристы сначала смотрят на определения терминов, потом на условия, потом на исключения.

  • Программирование в целом 💻
    В коде написано: «вызови функцию А, потом Б». Но компилятор или интерпретатор сначала обрабатывает импорт библиотек, парсит синтаксис, оптимизирует, и только потом «доходит» до исполнения.

В SQL — такая же история: пишем запрос сверху вниз, но база данных «читает» его по-своему. Про фактический порядок выполнения я написал подробно в своём канале На связи: SQL, так что если интересно — загляните 😉

Показать полностью
1

Таблицы в базах данных: где чаще всего "горит"

Когда мы слышим слова таблица, то сразу идет ассоциация со строками и столбцами. Но в базе данных - это не просто строки и столбцы, это мини вселенная со своими правилами и требованиями.

В своем канале На связи: SQL я рассказываю об особенностях языка SQL. Разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

Таблицы в базах данных: где чаще всего "горит" Моральная поддержка, Мотивация, SQL, Аналитик, Аналитика, Анализ данных, База данных, Самообразование, Смена профессии, Смена работы, Данные, Microsoft Excel, Длиннопост

И для формирования таблиц в БД есть свои требования, нюансы и особенности.

Очень часто аналитики сталкиваются со следующими проблемами при работе с данными:

Слишком много столбцов

Иногда пытаются «запихнуть всё» в одну таблицу. Получается «широкая простыня» с сотнями колонок.
Такой подход приводит к тому, что становится неудобно работать, запросы тормозят, а половина столбцов вообще пустая.

В этом случае необходимо прибегать к нормализации данных — разносить данные по отдельным связанным таблицам.

Грубо говоря, нормализация - это способ организации данных. Что именно хранится, где именно хранится и как все, что хранится, связано между собой.

Дублирование данных

В таблице могут храниться одни и те же данные по 100 раз (например, имя клиента в каждом заказе).

Это приводит к сложности обновления — изменил телефон в одном месте, а в другом он остался старым; объем БД растет, что требует увеличения ресурсов для работы с данными.

В этом случае необходимо выносить повторяющиеся данные в отдельные таблицы и связывать ключами.

И это тоже про нормализацию данных.

Пустые ячейки (NULL)

Есть поле, но оно ничем не заполнено. И тогда аналитик задается вопросом: что это значит? Что данных просто нет (их никто не вносит), данные вносят, но они потерялись при загрузке в таблицу, либо эти данные необходимо воспринимать как равные нулю...

В этом случае необходимо сначала посмотреть требования к источнику данных, есть ли там обязательность их заполнения. Если данные обязательны к заполнению, то стоит рассмотреть ETL (Extract Transform Load - извлечение, преобразование и загрузка) процесс данных.

И от полученных результатов принимать решение как расценивать NULL данные.

Неправильный тип данных

Телефон хранят как INT, даты — как текст, деньги — как FLOAT.
Такой подход приводит к тому, что в телефоне «съедается» +7, даты не сортируются, а деньги теряют копейки.

И аналитик не может корректно обрабатывать данные, что приводит либо к ошибкам в результатах, либо к увеличению этапа обработки данных для выполнения какой-либо аналитики.

В этом случае: только правильное использование типов данных.

Нет ключей и индексов

Ключи нам нужны, чтобы однозначно идентифицировать данные и связывать таблицы между собой.

Есть первичный ключ (Primary Key) и внешний ключ (Foreign Key)
Первичный ключ - это уникальный идентификатор. Например есть два Ивановых Ивана Ивановича, но у них будут разные ID. Этот ID будет однозначно идентифицировать каждого из них.
Внешний ключ - это ссылка на другую таблицу. Например есть таблица заказов и в ней есть поле client_id. Это поле будет ссылаться на ID нашего Иванова Ивана Ивановича в таблице с персональными данными.

Индексы нам нужны для ускорения поиска.

Представь, у тебя есть огромная книга (миллионы строк в таблице). Если ты ищешь слово вручную — придётся листать страницу за страницей.

Но если есть алфавитный указатель (индекс) — ты сразу находишь нужное слово.

Примеры:

  • Поиск клиента по номеру телефона

  • Поиск заказов по дате

  • Поиск товаров по категории

Индексы ускоряют запросы в разы, но требуют памяти и времени на обновление (поэтому ими злоупотреблять тоже не стоит).

Слияние «всего подряд»

Если таблицу использовать как свалку — складывать туда и клиентов, и товары, и заказы — это как в одной кастрюле сварить борщ, компот и макароны.
Итог: никто не понимает, что с этим есть.

А в канале На связи: SQL уже первые посты про структуры запросов и JOIN ждут тебя.

Если тебе нужна поддержка и мотивация или просто сопутствующие слова для твоего развития, то приходи в канала Сила слов. Там каждое утро тебя ждет мотивационное и поддерживающее послание.

Показать полностью
0

Из чего состоит база данных? Простыми словами и с примерами из жизни

База данных — это не какой-то страшный монстр из IT-страшилок. Это, скорее, твой самый организованный шкаф, в котором всё лежит по полочкам и ты всегда знаешь, где что искать.

Вот разберёмся, из чего она состоит и почему это важно.

Особенности и нюансы, а также интересные факты, задачи и многое другое можно прочитать в моем канале На связи: SQL Я его веду с нуля, и рассказываю в публикациях информацию с самых основ. Подписывайся! Планирую разбирать там интересные аналитические задачи.

Из чего состоит база данных? Простыми словами и с примерами из жизни База данных, Microsoft Excel, Таблица, SQL, Аналитик, Аналитика, Самообразование

1. Таблицы — это как списки гостей на твоей вадьбе

Ты ведь когда-нибудь составлял(а) список гостей? Кто приглашён, как будет добираться, где остановится, откуда забрать? Вот это и есть таблица — аккуратный список, где каждая строка — отдельный гость, а каждый столбец — важная инфа про него.

Представь: ты пытаешься запомнить, кто из гостей любит веганский салат, а кто шоколадный торт. В таблице всё чётко — не надо ломать голову!

2. Поля (столбцы) — это категории, которые помогают разложить данные по полочкам

Поле — это как коробка с надписью «Имя», «Телефон», «Принёс подарок». Без таких коробок у тебя бы всё смешалось в одну кучу — как если бы носки и трусы лежали в одной коробке и искать их было бы сплошным кошмаром.

Жизненный пример: когда мама говорит: «Твои учебники на полке, а игрушки — в коробке», она на самом деле говорит о полях — разделении информации.

3. Записи (строки) — это конкретные данные, про каждого гостя или объект

Строка — это, грубо говоря, одна полная карточка гостя: «Оля, +7 900..., принесла торт». Не нужно ничего додумывать — всё записано и понятно.

Представь: хочешь позвонить Оле? Заглядываешь в её строку — и все контакты под рукой.

А теперь маленький секрет базы данных:

Представь, что у тебя не просто один список гостей, а сотни списков — по разным праздникам, по родственникам, по коллегам. И ты хочешь быстро узнать, кто из них умеет играть на гитаре или кто приносил на последний праздник вино.

Здесь на помощь приходят…

  • Индексы — как яркие закладки в книгах. Без них поиск был бы как искать иголку в стоге сена.

  • Связи (отношения) — это как ниточки между гостями и подарками. Они показывают, кто что принёс, кто с кем пришёл и кто кому друг.

  • Представления (вьюшки) — это твои любимые списки, которые показывают только нужных гостей — например, только тех, кто любит танцевать.

  • Процедуры и триггеры — это автоматические помощники, которые, например, сразу отправят напоминание гостю, если он не подтвердил участие.


Почему это важно?

Потому что без базы данных твой «шкаф» превратится в хаос: всё смешается, запутается, и ты будешь тратить часы, чтобы найти нужную информацию.

База данных — это как суперорганайзер твоей жизни, только для данных.

Ну а в своем канале На связи: SQL я пишу об особенностях языка SQL, интересных ситуациях и все это пытаюсь объяснить простым доступных языком.

Показать полностью 1

База данных: гардероб, кухня и мастерская в одном месте

Представьте себе шкаф у вас дома. В одном отделении лежат полотенца, в другом — футболки, в третьем — кастрюли (если шкаф на кухне). Каждая полка — для своих вещей, чтобы потом легко было найти.

База данных (БД) — это тот же шкаф, только для информации. Она хранит данные так, чтобы их можно было легко положить, достать и разложить по порядку.

Если тебе интересно узнать больше про базы данных и SQL — заглядывай в мой телеграм-канал sql_in_touch. Там я просто и понятно рассказываю, как работать с SQL, разбираю практические примеры и делюсь лайфхаками для начинающих. Буду рада видеть тебя в числе подписчиков и вместе разбираться в мире данных!

База данных: гардероб, кухня и мастерская в одном месте Аналитика, Аналитик, Microsoft Excel, База данных, Данные, Анализ данных, SQL, Отчет, Визуализация, Визуализация данных, Postgresql, Oracle, Образование, Длиннопост

В нашей жизни есть разные шкафы. Платяной шкаф, кухонный шкаф, шкаф с инструментами и т.д. Так и в мире данных есть разные БД.

Виды баз данных и зачем они нужны

1. Реляционные БД (табличные)

  • Данные хранятся в таблицах (как в Excel, только гораздо умнее).

  • Таблицы связаны между собой: в одной лежат заказы, в другой — клиенты, и они связаны по уникальному номеру клиента.

  • Примеры: MySQL, PostgreSQL, Oracle.

  • 📌 Где хороши: когда данные структурированы и связи между ними важны (интернет-магазин, банковские операции).

💡 Пример:
У меня в одном ящике лежит нижнее белье, в другом — футболки, а на плечиках висят брюки и пиджаки. Мне нужно быстро собрать наряд для собеседования. Я открываю нужные ящики и беру нужные вещи — так я собираю образ. Да, бывает, что я надену на себя вещи, которые не сочетаются между собой. Но в данном контексте это будет означать, что я не ограничила выборку условиями. А все необходимые составляющие: футболка, брюки, пиджак и т.д. будут выбраны из нужного ящика или вешалки.

Так и база данных — она состоит из разных «ящиков» (таблиц), в которых хранится разная информация. Но чтобы получить полный «наряд» (то есть ответ на запрос), система быстро соединяет данные из этих ящиков и выдает нужный результат. Это и есть работа с базой данных — быстро и удобно находить нужные сведения, даже если они лежат в разных местах.

2. Документоориентированные БД

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

  • Данные хранятся в виде документов (JSON, XML) — как целые досье.

  • Каждый документ может содержать разную структуру, без строгих таблиц.

Примеры: MongoDB, CouchDB.

💡 Пример:, у стилиста есть папка с данными о каждом клиенте: цвет волос, любимый стиль, что уже покупали, фотографии образов. У одного клиента в папке может быть описание прически, у другого — заметки про аксессуары, у третьего — список любимых магазинов. И это нормально, потому что каждая папка индивидуальна и хранит то, что важно именно для этого клиента.

📌 Где такие базы удобны? Когда данные часто меняются и не всегда бывают одинаковыми — например, каталоги товаров с разными характеристиками или профили пользователей с разным набором информации.

3. Ключ-значение

Представь повара на кухне, у которого на полках стоят контейнеры с приправами. На каждом контейнере — ярлычок: «Соль», «Перец», «Базилик». Повар сразу видит, где что лежит, и может быстро взять нужную специю, не тратя время на поиски.

В базах данных типа ключ-значение, например Redis или Memcached, всё устроено похожим образом: есть «ключ» — это как ярлычок на контейнере, и «значение» — содержимое внутри. Когда нужна информация, система быстро находит значение по ключу — без лишних сложностей и долгих поисков.

📌 Где такие базы классно работают? Когда нужна очень быстрая реакция: кэширование данных, хранение настроек, сессий пользователей, временных значений — чтобы всё на кухне (то есть в системе) шло как по маслу.

4. Графовые базы данных

Соцсети — отличный пример того, как работают графовые базы данных.

В таких базах информация хранится в виде «узлов» — это могут быть пользователи, группы, посты, события. «Связи» — это отношения между этими узлами: кто с кем дружит, кто подписан на кого, кто лайкнул чей пост, кто участвует в каком событии.

В итоге получается огромная сеть — граф — где можно быстро понять, кто ваши друзья, кто из них общается между собой, какие группы и интересы вас объединяют.

📌 Где полезны графовые БД? В соцсетях для построения друзей и рекомендаций, в картах для прокладывания маршрутов, в системах рекомендаций товаров.

💡 Пример:
Представь, что у тебя есть большая компания, и тебе нужно понять, кто с кем работает вместе, кто кому помогает и кто отвечает за какие задачи.

Каждый сотрудник — это «узел», а связи между ними — это совместные проекты, встречи или переписка. Так можно быстро увидеть, кто является центром коммуникаций, кто с кем тесно взаимодействует и как лучше организовать работу команды.

Графовая база поможет быстро найти нужных людей и понять, как информация и задачи «текут» внутри компании

Итог

База данных — это способ хранить и упорядочивать данные, как мы упорядочиваем вещи дома или в рабочем шкафу.

  • Хотите чёткий порядок и строгие связи? → Реляционные БД.

  • Нужна гибкость и разная структура? → Документоориентированные.

  • Важна молниеносная скорость для простых данных? → Ключ-значение.

  • Важны сложные связи? → Графовые.

Как у хорошей хозяйки или стилиста — в базе всё лежит там, где нужно, и всегда можно быстро достать.

Показать полностью 1

Зачем нужен SQL, если есть Python, R, Java и другие?

И так, зачем же вообще SQL, если есть другие языки?
А другие языки это какие?

  • Python

  • R

  • C++

  • Java

  • и еще десятки других

Зачем нужен SQL, если есть Python, R, Java и другие? SQL, Аналитик, Аналитика, Обучение, База данных, Microsoft Excel, Большие данные, Самообразование, Новая жизнь, Профессия, Длиннопост

Возникает закономерный вопрос:
А нельзя было остановиться на двух? Или хотя бы на одном универсальном языке?

Языки как инструменты: у каждого своя задача

Когда появляется новая область (веб, большие данные, AI), или старые инструменты становятся неудобными — создают новые.
Это не про прихоти разработчиков, а про реальные задачи, которые требуют удобных решений.

Представьте себе набор инструментов:

🔩 Гвозди мы забиваем молотком, а не микроскопом.
🔬 Клетки изучают под микроскопом, а не с помощью отвёртки.

То же самое с языками программирования и работы с данными:

SQL - Язык запросов к базам данных: выборка, фильтрация, агрегация
Python - Универсальный язык. Подходит для аналитики, автоматизации, ML
R - Cпециалист по статистике, визуализации, исследованиям
C++ - Высокопроизводительные системы, игры, устройства
Java - Web-приложения, крупные корпоративные сервисы

Почему я все равно делаю акцент на SQL?

Потому что данные чаще всего живут в базах данных.
И чтобы что-то с ними сделать — их нужно сначала достать.

И для этого тебе необходимо владеть языком общения с БД (база данных).

Даже если ты аналитик и работаешь в Python, тебе всё равно нужно:
(взять библиотеку для анализа и обработки данных - pandas, подключиться к БД - connection и выполнить запрос SELECT * FROM orders WHERE status = 'completed' с помощью функции read_sql)

import pandas as pd

df = pd.read_sql("SELECT * FROM orders WHERE status = 'completed'", connection)

SQL запросы работают на стороне базы (сервер) - извлекают и обрабатывают данные, а pandas - на стороне Python (локально) - анализирует, готовит, визуализирует.

Т.е. ты сначала с помощью SQL достаешь нужные данные, а потом в pandas можешь продолжать анализ, обработку и визуализацию.

Но с анализом и обработкой может справится и SQL, а вот визуализировать с его помощью не получится.

SQL — это основа

  • SQL не про машинное обучение.

  • Не про красивую визуализацию.

  • Не про сложную логику приложений.

👉 Он про доступ к данным:
создавать таблицы, извлекать записи, фильтровать, агрегировать, связывать таблицы между собой.

Именно поэтому:

  • SQL учат в любой профессии, связанной с данными.

  • SQL — базовый язык, без которого работа аналитика невозможна.

🕰 Историческая справка

  • SQL появился в 1974 году в IBM. Его задача: удобно вытаскивать данные из баз.

  • Python появился в 1991 году как читаемый, простой, универсальный язык для задач общего назначения.

  • R стал популярен среди учёных и исследователей для статистических вычислений и графиков.

☕ SQL — это как кофе к утру

Ты можешь быть профи в Python, R или Java, но если не знаешь SQL —
ты всегда будешь зависеть от кого-то, кто достаёт данные за тебя.

SQL — не заменитель, а необходимое дополнение.

В моем канале На связи: SQL уже появился первый пост. Я его веду с нуля и планирую наполнять практическим и полезным контентом в рамках серии постов Знакомство с SQL. Присоединяйся!!!

Ну и мои мотивационные послания в канале Сила слов продолжают мотивировать меня и других к действиям! Если тебе нужна утренняя доза веры в себя, то тебе явно сюда - Присоединяйся к Сила слов

Показать полностью

Что такое SQL? Как спрашивать базы данных, где лежат подгузники?

Сегодня профессия аналитик данных на слуху у многих. И это неудивительно: мы живем в мире, где ежедневно производим огромные объемы информации. Чуть меньше из этого мы храним в структурированном виде. И совсем малую часть — действительно используем.

Вот здесь и появляются аналитики данных. Они — те самые, кто умеет собирать, обрабатывать, хранить и интерпретировать данные так, чтобы на их основе можно было принимать решения.

Что такое SQL? Как спрашивать  базы данных, где лежат подгузники? Аналитик, Аналитика, SQL, Анализ данных, База данных, Поисковые запросы, Join, Саморазвитие, Профессия, Студенты, Декрет, Длиннопост

Но очень многих пугает это завуалированное понятие "аналитик данных".

Когда люди сталкиваются с понятием SQL, то самое первое, что им выдает любой поиск - это определение что такое SQL.

SQL (Structured Query Language) — язык структурированных запросов. Предназначен для работы с реляционными базами данных (БД) — массивами информации, которые связаны между собой и представлены в виде таблиц.

И сразу кажется, что SQL — это что-то очень сложное и скучное. Мол, только серьезные люди решают серьезные кейсы, строят модели, прогнозируют будущее бизнеса и ведут суровые Excel-файлы.

Но даже знакомство с SQL можно сделать проще и даже немного веселее.

Почему SQL — это как мамин ответ "где мои носки"

Да, многие скажут, что "не веселится" идут в аналитику, а решать реальные, серьезные кейсы, помогать бизнесу строить свои процессы, получать прибыль и т.д.
Да, это все так, но этап знакомство с SQL может быть и "веселее". Если хотя бы информацию для начинающих и тех, кто просто знакомится с SQL преподносить более "приземленным" способом.

Да, серьезные вещи надо обсуждать серьезным языком. Но ведь нас в школе не сразу заставляют читать Войну и мир Толстого, а дают Букварь с картинками. А картинки там, чтобы была ассоциация с тем, что уже знакомо, и чтобы веселее было изучать.

Так и с SQL. Это действительно серьезный язык запросов (не программирования), но на нём говорят и мамы, и папы, и дизайнеры, и строители — просто не знают, что это называется SQL.

Пример №1: мама как база данных

Мама каждый день слышит:

  • где мои синие носки для спорта

  • где лежат подгузники

  • где штаны от костюма

  • а что такое планета?

Она знает, где что лежит. Мама — это не просто база знаний, она ещё и движок запросов:

SELECT *

FROM Flat

WHERE things = 'подгузники';

Квартира — это база данных, тумбочки/шкафы — таблицы, мама — мастер SQL-запросов.

Пример №2: дизайнер и объединение таблиц

Дизайнер интерьера создает гармоничное пространство, объединяя, казалось бы, разные стили, цвета, формы. Но у них есть что-то общее, что делает интерьер целостным.

SQL делает то же самое:

SELECT *

FROM Furniture

JOIN Textiles

ON Furniture.color = Textiles.color;

Мы объединяем данные из разных таблиц, чтобы получить единую картину — понятную и полезную.

Кому будет интересна эта серия постов?

Я готовлю серию постов о SQL — простыми словами, с жизненными аналогиями, с нуля. Это будет интересно:

  • студентам и новичкам в аналитике

  • тем, кто хочет сменить сферу и понять, "что там у этих дата-людей"

  • тем, кто хочет просто научиться разговаривать с данными на их языке

Если вы уже знакомы с SQL — приходите в комментарии! Расскажите, что помогло вам освоить этот язык? Что может "завлечь" новичков?

А ещё у меня появился канал про SQL

Пока там только один подписчик — я сама :) Но планов много:
📊 практичные посты
📚 объяснение синтаксиса без занудства
🧩 разбор типичных задач аналитиков

👉 Присоединяйтесь: На связи: SQL

И, конечно, мой мотивационный канал продолжает радовать короткими сообщениями, которые настраивают на день:
Сила слов

SQL — это не страшно. Это просто способ спросить: "Где лежат подгузники?"

Показать полностью 1
Отличная работа, все прочитано!