Строки и приведение типов: вопросы для собеседования (часть 3)
LIKE, SUBSTRING, CONCAT, TRIM, CAST, регулярные выражения — строковые функции нужны для парсинга и очистки данных. На собеседовании могут попросить извлечь домен из email, привести строку к числу или разобрать URL. Эти задачи проверяют практический опыт работы с «грязными» данными.
Вопросы 11–15 из 20
11На ревью вы видите выражение `CAST(user_id AS text)`. Какой вариант с `::type` является эквивалентным по смыслу?
A`user_id:text`
B`CAST(text AS user_id)`
C`user_id::text`
D`user_id::int`
Ответ: `::type` — сокращённая форма явного каста, эквивалентная `CAST(... AS type)`.
В Postgres-подобных СУБД два распространённых синтаксиса явного приведения типов — `CAST(x AS type)` и `x::type`. Оба делают намерение запроса явным и уменьшают риск скрытых проблем из-за неявных приведений.
12У вас есть таблицы `users(email)` и `marketing_signups(email)`. В одной системе email сохраняется как `Ivan@Example.com`, в другой — `ivan@example.com`. Какой подход в `JOIN` чаще всего решает проблему без изменения данных в таблицах?
AСделать `JOIN` как есть: `users.email = marketing_signups.email`, база сама сопоставит регистр.
BСравнивать нормализованные значения: `LOWER(users.email) = LOWER(marketing_signups.email)`.
CСравнивать по длине: `LENGTH(users.email) = LENGTH(marketing_signups.email)`.
DПривести email к числу: `CAST(users.email AS int) = CAST(marketing_signups.email AS int)`.
Ответ: Для регистронезависимого сравнения текст часто нормализуют через `LOWER` или `UPPER` на обеих сторонах.
Сравнение строк в SQL обычно чувствительно к регистру. Если источники данных сохраняют email в разном регистре, прямое сравнение в `JOIN` даст пропуски. Нормализация через `LOWER(...)` на обеих сторонах делает сравнение стабильным и предсказуемым.
13Поле `price_text` хранит цены как текст, например `2`, `10`, `100`. Аналитик написал фильтр `WHERE price_text > '10'` и получил странные результаты. Что нужно поменять, если сравнение должно быть числовым?
AОставить как есть: сравнение `'2' > '10'` корректно для чисел.
BЗаменить `>` на `!=`.
CСделать явный каст и сравнивать как число: `WHERE CAST(price_text AS int) > 10`.
DСделать `WHERE LOWER(price_text) > '10'`.
Ответ: Сравнение текстов и чисел — разные операции: для числовой логики нужен явный каст.
Текст сравнивается лексикографически, поэтому `'100'` может вести себя не так, как число 100. Если поле хранится как текст, аналитик должен явно привести его к числовому типу через `CAST` или `::type`. Тогда `WHERE` начнет работать в соответствии с бизнес-смыслом.
14В таблице `events` поле `event_date_text` хранит дату как текст в формате `YYYY-MM-DD`. Вы хотите считать метрики по неделям и использовать функции дат. Что логичнее сделать в запросе?
AПривести к типу даты: `CAST(event_date_text AS date)` или `event_date_text::date`.
BПривести к числу: `CAST(event_date_text AS int)`.
CПривести к нижнему регистру: `LOWER(event_date_text)`.
DУбрать пробелы: `TRIM(event_date_text)` и больше ничего.
Ответ: Если дальше нужны операции с датами, лучше явно привести текст к типу даты.
Даже если строковые даты иногда «сравниваются правильно», это всё равно строковый тип: функции дат, группировки по периодам и проверки корректности формата становятся проблемными. Явный каст в `date` делает логику запроса прозрачной и снижает риск неожиданных ошибок при дальнейшем использовании поля.
15В поле `phone` хранится строка из 10 цифр, например `9991234567`. Вам нужен код региона — первые 3 цифры — для группировки. Какое выражение подходит?
A`TRIM(phone)`
B`SUBSTRING(phone, 1, 3)`
C`CAST(phone AS int)`
D`SUBSTRING(phone, 4, 3)`
Ответ: `SUBSTRING` помогает извлекать нужные части строки для группировок и признаков.
Для аналитики часто нужно выделять часть строки: первые символы, кусок по позиции и т.д. В простом случае с фиксированной длиной `SUBSTRING(phone, 1, 3)` вернёт первые 3 символа (код региона). Это удобно для `GROUP BY` и построения срезов.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram