VelStyling

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

Об этом порассуждаю ниже.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL.
Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Разбор задач со скользящим окном уже в канале.
Присоединяйся!

И так

Сейчас нейросети могут создавать "много чего". Могут в принципе написать план создания отдельного государства. Я почти уверена, что каждый второй точно пользуется нейросетями для облегчения своей жизни. Почти каждая компания говорит о том, что выполнение рутинных задач будут замещены ИИ. Это и хорошо и плохо, как говорится, у любой стороны есть две медали. С одной стороны мы сможем освободившееся время выделить на что-то другое, а с другой стороны - это изменение в штатном расписании.

Так зачем же сейчас изучать SQL, если есть ИИ, который за нас может написать весь код, мы даже можем загрузить сырые данные и попросить проанализировать его, что это за данные, чтобы потом, при постановке задачи, учесть все нюансы в промте.

Рассмотрим следующий кейс:

Ты - аналитик, у тебя есть таблица с данными. Ты понимаешь бизнес:
- знаешь, какие показатели нужны
- знаешь как они считаются
- знаешь, что такое выручка, конверсия, средний чек и т.д.

Ты открываешь ИИ и говоришь:

Вот данные. Напиши SQL-запрос, который посчитает эти метрики. Учти NULL, особенности данных и вот эти условия

Все перечислил, все вроде бы учел.

ИИ пишет запрос.
Он выглядит красиво. Он даже выполняется.
Цифры выводятся.

И вот здесь возникает главный вопрос:
а что именно ты получил?

Ты дал данные, ИИ проанализировал, составил запрос, учел там формат даты, NULL и т.п., выдал результат. А как понять - можно ли верить этим данным? А почему получилось именно это число?

Т.е. появляется вопрос: а почему именно так?

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

Нейросеть тебе на твои уточняющие вопросы дает комментарии и в этот момент, ты либо веришь полученным ответам, либо идешь проверять.

А чтобы проверить, тебе надо лезть в данные. И вот тут знания SQL тебе явно пригодятся.
Ты можешь от ИИ получать на вопрос: "Почему выросла конверсия?", например, такие ответы: "Конверсия выросла из-за изменения структуры пользователей."

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

Ты и эти вопросы можешь задавать нейронке.
Но без SQL ты можешь остаться на уровне объяснений, а не на уровне доказательств.

По факту:

SQL нужен не для того, чтобы:

• писать сложные запросы

• помнить синтаксис

• быть «технарём»

SQL нужен, чтобы в любой момент сказать:

«Я могу сам(а) проверить».

Это ключевое.

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

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

И тут ты возвращаешься к началу. Чтобы задать корректный промт для нейросети, ты должен сначала проанализировать данные, чтобы учесть все условия для вычисления показателей.

А чтобы проанализировать нужно самому написать SELECT-ы различного рода.

В моем канале На связи: SQL все простыми словами и с конкретными примерами.

Подписывайся!

Сегодня последний день 2025 года.
И даже не крайний, как многие любят говорить.

Вообще, 31 декабря - это не про чтение постов.

Это про:

- беготню по магазинам
- салаты "на глаз"
- запах мандаринов
- фоновые фильмы ("Ирония судьбы", например)
- и тихую надежду, что следующий год будет чуть мягче, чем предыдущий

Поэтому пусть этот пост будет просто точкой.
Тихой, спокойной точкой в конце года.

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

А если вдруг вы из тех, кто 31 декабря всё равно думает про цифры, данные и "а что там в статистике за год" - оставлю здесь ссылку на свой телеграм-канал.

На связи SQL

Там я пишу про SQL и базы данных:
- как не бояться JOIN
- зачем нужен GROUP BY
- почему NULL ≠ 0
- и как вообще начать понимать, что происходит в запросах

Ну и разбор задач по накопительной сумме и скользящему окну уже выложены

Канал я веду с нуля подписчиков, без крика и без пафоса.

Но сегодня - не об этом.
Сегодня просто до встречи в новом году 🤍
Берегите себя и пусть 2026 будет чуть добрее.

Паспортные данные - это персональная информация. Она нужна, чтобы идентифицировать человеке.

Но как их хранить, что с ними делать, кому давать доступ?

Это очень часто становится развилкой в организации хранения данных.

Об этом ниже.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0.
Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

Паспорт - это не просто набор цифр.
Это ключ к человеку: по нему можно понять, кто он, где живёт, какие услуги получал и что с ним происходило в системе.

Именно поэтому вокруг паспортных данных всегда много вопросов:

• Можно ли хранить паспорт в базе данных?

• Почему иногда по паспорту делают JOIN?

• Почему в одних системах паспорт виден полностью, а в других — нет?

Паспорт это не просто набор цифр.
Это ключ к человеку: по нему можно понять, кто он, где живёт, какие услуги получал и что с ним происходило в системе.

Именно поэтому вокруг паспортных данных всегда много вопросов:

• Можно ли хранить паспорт в базе данных?

• Почему иногда по паспорту делают JOIN?

• Почему в одних системах паспорт виден полностью, а в других — нет?

В идеальном мире паспортные данные:

1. Хранятся в базе данных
   Да, это важно сразу проговорить -
   👉 паспорт всё равно лежит в БД, иначе с ним просто невозможно работать.

2. Но не в открытом виде
   Это значит:

   • не просто текстом 1234 567890

   • не так, чтобы любой сотрудник мог его посмотреть запросом

3. Доступны только тем, кому действительно нужно
   Например:

   • пользователю в личном кабинете

   • сотруднику KYC / поддержки

   • системе проверки документов

В реальных системах ID клиента — не всегда надёжен.

Пример из жизни:

• человек зарегистрировался в системе

• потом пришёл снова, но:

  • с другим номером телефона

  • с другой почтой

  • через другой канал (офис / сайт / партнёр)

В итоге в базе:

• два разных client_id

• но один и тот же паспорт

👉 И это прямой сигнал:
это один и тот же человек

Поэтому в некоторых случаях:

• делают объединение (JOIN) по паспорту

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

Это особенно важно:

• в банках

• в финтехе

• в государственных системах

• в CDI (системах, которые собирают данные о клиентах из разных источников)

Тогда почему паспорт нельзя просто зашифровать и забыть?

Потому что с паспортом делают проверки и сравнения.

Например:

• «Этот паспорт уже есть в системе?»

• «Этот человек уже проходил идентификацию?»

• «Это новый клиент или старый?»

Если просто заменить паспорт на набор звёздочек: **** ****** - с ним не возможно напрямую работать

Поэтому часто используют подход:

• паспорт хранится в защищённом виде

• но система всё равно может:

  • сравнивать

  • находить совпадения

  • связывать записи

Когда паспорт виден в явном виде

Да, такие случаи есть. И они нормальны, если соблюдены условия.

1️⃣ Личные кабинеты пользователей

Пользователь:

• сам вводит паспорт

• сам его видит

• сам может исправить ошибку

Это допустимо, потому что:

• это его данные

• он дал согласие

• доступ есть только у него

2️⃣ Банковские и финтех-системы

Сотрудники:

• видят паспорт полностью

• но не напрямую из базы

• а через интерфейс системы

Важно:

• каждый просмотр логируется (записывается)

• есть роли доступа

• нельзя просто «посмотреть ради интереса»

3️⃣ CDI и KYC-системы

Это системы, которые:

• собирают данные о клиенте из разных источников

• проверяют документы

• подтверждают личность

Здесь паспорт:

• часто нужен целиком

• иначе невозможно выполнить проверку

Почему аналитики обычно не видят паспорт

Потому что:

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

• аналитике нужен идентификатор человека

Поэтому в аналитических базах:

• паспорт заменяют на client_id

• или на специальный технический ключ

👉 Это снижает риск утечек и ошибок.

В некоторых слоях хранения данных, паспорт хранится в виде хэша. Но надо помнить, что хэш ≠ шифрование

Хэширование - это дорога в одну сторону.
Есть еще метод шифрования и при его использование можно восстановить данные, если есть ключ.

Хэш не подходит, если паспорт нужно:

• показать пользователю

• передать в другую систему

• проверить вручную

Хэш не подходит, если паспорт нужно:

• показать пользователю

• передать в другую систему

• проверить вручную

Но тогда где хранится настоящий паспорт?

В реальных системах обычно два уровня хранения:

1️⃣ Паспорт в зашифрованном виде

• хранится в БД

• может быть расшифрован

• доступ есть только:

  • у сервиса

  • у строго ограниченного круга ролей

Это нужно, когда:

• пользователь открывает личный кабинет

• сотрудник банка смотрит данные

• идёт проверка документа

2️⃣ Хэш паспорта - для связей и аналитики

• используется для:

  • поиска дублей

  • объединения клиентов

  • JOIN между системами

• никогда не раскрывается наружу

👉 Аналитик работает с хэшом
👉 Операционная система - с зашифрованным паспортом

Почему нельзя хранить только хэш?

Потому что тогда:

• нельзя показать паспорт пользователю

• нельзя исправить ошибку

• нельзя передать данные в гос-сервис

• нельзя провести ручную проверку

Хэш отвечает только на вопрос:

«Совпадает или нет?»

Но не отвечает на вопрос:

«А что именно там написано?»

Можно ли «достать паспорт из хэша»?

Нет.
И если кто-то говорит, что «у нас хэшируется, но при необходимости мы восстанавливаем» -
👉 значит это не хэш, а шифрование.

В моем канале На связи: SQL все простыми словами и с конкретными примерами.
Подписывайся!

В далекие времена после университета, я работала специалистом по качеству данных.
Данные были клиентские: ФИО, адреса, телефоны, email. И надо было, чтобы данные были качественные. Для этого в компании использовалось ПО по стандартизации данных, надо было следить, чтобы ПО работало корректно, если замечаешь, что при обработке допущена ошибка, то выставляешь ТЗ на доработку, проверяешь, чтобы новый релиз работал как минимум не хуже чем предыдущий ну и т.д.

Так вот, хоть я и работала с клиентскими данными, но я не работала с БД. Хотя все данные лежали в БД. У меня там были выгрузки в Excel, их формировал кто-то другой. И я в Excel обрабатывала эти данных - надо было, чтобы процент плохих или неразобранных данных был меньше 3.

Перешла я в другую компанию - тоже на проект с качеством клиентских данных. И тут мне предлагают: "а давай мы тебе доступ к БД дадим, ты там будешь селектики делать, статистику считать". И тут у меня загорелись глаза. "Да, конечно, я хочу, но я ничего не знаю, не знаю как пользоваться, хотя в универе у меня был курс, связанный с базами данных. Но я ничего не помню. Так у меня началось осознанное знакомство с SQL.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0.
Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

Глаза горели, а руки делали в тот момент. Я начала знакомится, что такое БД, DWH, а потом стали появляться Data Lake.

Все эти слова (База данных, DWH, Data Lake) - это про совокупность данных. Везде здесь могут быть связи. Везде может использоваться одна и та же технология (PostgreSQL, S3, ClickHouse и т.д.)

Почему же, если это все про совокупность данных, стали появляться разные слова для этого?

Посмотрим на кусок мяса.
Мы его можем варить, жарить, мариновать.
Но это все равно остается мясом.

Получается, что мясо - это сырье.
А стейк, бульон, котлета - это не мясо, а БЛЮДА.

А теперь попробуем сделать проекцию на данные.

Данные = мясо.
БД/DWH/Data Lake - не мясо, а способ организации этого мяса

База данных - это технология хранения
DWH и Data Lake - это концепции организации данных

У DWH есть своя БД
У Data Lake - своя БД
Но не каждая БД - это DWH
И не каждая БД - это Data Lake

База данных - это как холодильник. Он хранит еду, ему все равно, будет ли это суп или торт.
БД - это "контейнер + правила":
- как хранить данные
- как читать
- как писать
- как обеспечивать целостность

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

Что же такое DWH?

Это ближе уже к готовому блюду. Его не переделывают, его едят и анализируют (это в идеале, конечно)

В DWH данные:
- приведены к единому виду
- нормализованы (чаше всего встречается 3-я форма нормализации - этого достаточно)
- уже очищены
- изменения задним числом недопустимы
Все это не про связи, это про правила жизни данных.

Тогда что включает в себя Data lake?

Озеро данных - это "склад без разборки"
Многие компании не знают, что пригодится завтра, поэтому максимально пытаются сохранить большее количество данных.
Данных действительно бывает много, не все они участвуют в бизнес-процессах и монетизируются. Но терять их никто не хочет.

Поэтому компании организовывают Озеро данных:
- данные хранятся как есть
- без очистки
- без структуры
- без гарантий
- связи между данными могут быть, а могут и нет

Но в некоторых данных встречала, что какие-либо отчеты формируются на данных из "озера".

Поэтому появляются термины, чтобы сказать:
- это БД, которая используется как DWH
- это БД, которая используется как Data Lake

В итоге, получается, что БД - это "где хранятся данные".
DWH и Data Lake - это как и в каком виде они там хранятся.

В моем канале На связи: SQL все простыми словами и с конкретными примерами.
Подписывайся!

Ну что, год подходит к концу. Новых собесов я не жду. Старые, я думаю, что тоже не воскреснут.

Два с половиной месяца я в активном поиске. Но сейчас думаю, что не совсем активном, а просто в открытом поиске.

Что по моим наблюдениям и результатам получилось

Об этом ниже

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0.
Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

В этом посте писала о том какие показатели HH озвучивает на текущий момент.

Из моих наблюдений:

• вакансии есть

• хороших вакансий - меньше

• прозрачности - ещё меньше

1.Череда собесов, которые дошли до оффера (если что, то за 2,5 месяца у меня только один оффер)

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

Собеседования прошли нормально.
По деньгам - дали верх вилки.
Я уже мысленно вышла на работу.

И тут нюанс.

Оказывается:

• оформление не в компанию

• а через аутсорс

• при этом на всех этапах собеседований не было ни одного человека из аутсорса

Вообще. Ни разу.

Возникает логичный вопрос:
👉 эта компания вообще знает, что я у них буду работать?

Дальше - ещё интереснее:

• договор «срочный, но как бы бессрочный»

• формулировка: «завершение договора зависит от завершающего этапа проекта»

• если заказчик решает закрыть проект - 3–4 дня, и компания вправе завершить трудовые отношения

Юридически - всё аккуратно.
По факту - никакой стабильности.

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

2.Загадочный звонок и рекрутер-фрилансер

Звонок.
Представление - максимально невнятное.

- Ваше резюме понравилось, возможно, вам подойдёт вакансия.

Я прошу ещё раз представиться и объяснить:

• кто вы

• от какой компании

• это инхаус или агентство

Выясняется:

• это физлицо

• работает «сама на себя»

• ищет кандидатов, чтобы случился мэтч с командой

Я прошу рассказать:

• что за компания

• что за проект

Ответ:

Я не могу назвать компанию из-за NDA. Вам скажут на техническом интервью.

Я честно пытаюсь понять:
— Как я могу подготовиться к мэтчу, если не знаю, что за компания и чем они вообще живут?

В итоге:

• перешли к цифрам

• по вилке не сошлись

• на этом всё закончилось

3.Хороший собес, плохое состояние и кошка Люся Афферистка

Аутсорсинговая компания:

• проекты в финтехе

• оформление в штат аутсорса

• ТК РФ

• договор не срочный

Назначают техническое интервью.
Я готовлюсь, повторяю, освежаю знания.

Но.

Вечером накануне:

• я занимаюсь малярными работами на объекте

• грунтовка, штукатурка, усталость лютая

• в тот период я жила у брата

А у брата появилась кошка.
Люся. Афферистка. Ориентал.
С таким голосом, что и врагу не пожелаешь.

Я приезжаю домой в час ночи, валюсь с ног, хочу уснуть.
А Люсе нужно играть. Она бегает, скачет, орёт. Спать не даёт.

На утро:

• я невыспавшаяся

• уставшая

• подключаюсь к собеседованию

И вот парадокс:
👉 это был самый адекватный технический собес из всех.

Спрашивали:

• строго по вакансии

• всё по делу

• без цирка и лишних "угадай, что я думаю"

Но я:

• туплю

• медленно соображаю

• словарный запас - ниже плинтуса

В итоге - не дотянула. И здесь я поняла, что если ты не выспался, заболел или что-то пошло не по плану, то лучше попросить перенести собеседование.

4.Техническое интервью без техники

Компания делает ПО для миграционной службы.
По описанию - аналитик, но по факту им нужен BI-специалист.

Техническое интервью.
И… мы просто разговариваем.

• про мой опыт

• про компании

• про проекты

Первые 20 минут - класс, комфортно.
Потом я начинаю смотреть на время и думать:

- А где задачи?
- Где SQL?
- Где хоть что-нибудь техническое?

Ничего.
Ни кода.
Ни задач.
Ни кейсов.

После этого собеса - обратной связи не было вообще.

Вот такие 4 блока пока могу выделить из моего опыта конца 2025 года.

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

или почему один запрос меняет данные, а другой — саму таблицу

Сегодня поговорим об изменениях.

В своем посте вот тут я уже писала об UPDATE

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

Если коротко то:
UPDATE - это команда для изменения значений в строках.
Таблица остаётся той же самой, структура не меняется - меняются только данные.

Базовый синтаксис:

UPDATE table_name

SET column = value

WHERE condition;

• SET — что именно меняем

• WHERE — какие строки

UPDATE:

• может блокировать строки

• работает внутри транзакции

• откатывается через ROLLBACK

Что же такое ALTER TABLE?

ALTER - это команда для изменения структуры таблицы:

• добавить столбец

• удалить столбец

• изменить тип данных

• переименовать столбец

По-простому:

ALTER — это «переделать бланк», а не вписать новые данные.

Базовый синтаксис:

ALTER TABLE table_name

ACTION;

Где ACTION — это то, что ты делаешь со структурой.

Самые частые варианты ALTER

➕ Добавить столбец

ALTER TABLE users

ADD COLUMN age INT;

✏️ Переименовать столбец

ALTER TABLE users

RENAME COLUMN name TO full_name;

🔄 Изменить тип данных

ALTER TABLE users

ALTER COLUMN age TYPE BIGINT;

❌ Удалить столбец

ALTER TABLE users

DROP COLUMN age;

Пример из жизни

Раньше ты не хранила возраст пользователей.
Потом бизнес сказал: «Нужно».

➡️ Это ALTER, потому что:

• раньше столбца не было

• данные тут ни при чём

Главное различие - в одной таблице: