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

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

А пока подписывайся на мой канал На связи: 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 все простыми словами и с конкретными примерами.
Подписывайся!

XiYan-SQL - это open-source решение, позволяющее генерировать, анализировать и выполнять SQL-запросы с использованием больших языковых моделей. Инструмент ориентирован на ускорение исследования данных и автоматизацию рутинных операций, связанных с запросами к базе.

Ключевые возможности:

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

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

- Поддержка нескольких СУБД - PostgreSQL, MySQL, SQLite и другие.

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

Ссылка

Источник

В далекие времена после университета, я работала специалистом по качеству данных.
Данные были клиентские: ФИО, адреса, телефоны, 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 все простыми словами и с конкретными примерами.
Подписывайся!