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

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

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

Об этом ниже.

А пока подписывайся на мой канал На связи: 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, потому что:

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

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

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