SQL Ready | Базы Данных

Почему CONCAT_WS в PostgreSQL часто лучше обычной конкатенации строк! Есть такие SQL-функции, которые вроде бы выглядят слишком простыми, чтобы о них писать отдельный пост. Но именно они часто убирают кучу мелких проблем в реальных проектах, CONCAT_WS — хороший пример. Когда работаешь с тестовыми данными, кажется, что собрать строку очень просто. Есть имя, фамилия, отчество — соединяем их через пробел и получаем красивый результат. Обычно первый вариант выглядит так: SELECT first_name || ' ' || middle_name || ' ' || last_name AS full_name FROM users; На первый взгляд всё нормально. Но потом база начинает жить настоящими данными. У одного пользователя нет отчества. У другого не заполнена фамилия. После миграции часть полей приходит пустыми. И вот здесь простой запрос начинает вести себя не так, как ожидает разработчик. Например: first_name = 'John' middle_name = NULL last_name = 'Smith' Кажется логичным получить: John Smith Но PostgreSQL вернёт: NULL Причина в том, что NULL — это не пустое значение. Это отсутствие значения. При обычной конкатенации строк неизвестная часть делает неизвестным весь результат. Конечно, можно начать добавлять COALESCE: SELECT first_name || ' ' || COALESCE(middle_name || ' ', '') || last_name FROM users; Для двух-трёх полей это ещё нормально. Но в реальном запросе таких частей может быть намного больше: адрес, название компании, описание товара, дополнительные параметры. И постепенно вместо простой сборки строки появляется большая конструкция из проверок. В PostgreSQL для таких задач есть более удобный вариант: SELECT CONCAT_WS( ' ', first_name, middle_name, last_name ) AS full_name FROM users; CONCAT_WS расшифровывается как "concatenate with separator". Первый аргумент — разделитель, который нужно использовать между значениями. Главная особенность в том, что функция сама пропускает NULL. То есть: John + NULL + Smith превратится в: John Smith а не в строку с лишним пробелом или неожиданный NULL. На практике это особенно удобно, когда собираете данные для отображения пользователю. Например, адрес: Germany, Berlin, Alexanderplatz 10 может состоять из нескольких частей, но квартира или дополнительный номер могут отсутствовать. Не хочется писать отдельные проверки для каждого поля только ради красивого вывода. Но есть нюанс, который часто забывают. CONCAT_WS пропускает NULL, но пустую строку считает настоящим значением. Например, после загрузки данных из CSV можно получить: middle_name = '' Для пользователя это выглядит так же, как отсутствие значения. Но PostgreSQL различает эти случаи. В результате можно получить: John Smith с двойным пробелом. Поэтому в системах, где данные приходят из разных источников, часто сначала нормализуют значения: NULLIF(middle_name, '') После этого пустые строки становятся NULL, и CONCAT_WS уже работает предсказуемо. На небольших примерах это кажется мелочью. Но когда у тебя несколько миллионов записей и данные собираются из разных сервисов, именно такие детали начинают влиять на качество данных и количество лишнего кода. 🔥 CONCAT_WS — хороший пример того, как правильный инструмент делает SQL проще. Если нужно собрать строку из нескольких необязательных полей — часто лучше использовать её, чем вручную обрабатывать каждый NULL. ➡️ SQL Ready | #практика

Пачку офферов заказывали? О всех трудоустройствах через ИИ-ассистента Софи ребята узнают от пользователей. И какой же кайф, когда они делятся своими историями. Вот так в чате узнали сразу о трех новых офферах: • Кейс Сергея - 2 недели в Софи и 2 оффера. • Кейс Елены - 1 неделя в Софи и оффер спустя 10 лет перерыва в работе. Елене 52 года. • Кейс Юлии - 1 месяц в Софи, свитчер из финансового аналитика в разработчика SQL. И еще один оффер🎉 Искренние поздравления ребятам и удачи им на новой работе! В следующий раз доступ в Софи откроется уже 21 июля. Если хочешь получить 3 дня бесплатного доступа - подписывайся на этот канал, все анонсы будут там.

📂 Напоминалка по шардингу данных! Например, range-based шардинг делит данные по диапазонам значений, hash-based — распределяет записи через хэш-функцию, а consistent hashing помогает минимизировать перераспределение данных при добавлении новых нод. На картинке — 4 алгоритма шардинга, которые полезно знать при проектировании масштабируемых систем и высоконагруженных баз данных. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Обычное сравнение через = и != ломается, как только появляется NULL! old_value IS DISTINCT FROM new_value В SQL NULL никогда не равен даже другому NULL, поэтому сравнение начинает вести себя не так, как ожидается. SELECT NULL = NULL, NULL != NULL; Оба выражения вернут не TRUE и не FALSE, а NULL. Именно из-за этого часто ломается логика сравнения. SELECT * FROM users WHERE old_email != new_email; Кажется, что запрос покажет все изменённые email. Но если одно из значений NULL, строка может просто не попасть в выборку. Для таких случаев в PostgreSQL есть специальный оператор. SELECT * FROM users WHERE old_email IS DISTINCT FROM new_email; Теперь NULL корректно участвует в сравнении. PostgreSQL считает NULL обычным сравниваемым состоянием. NULL IS DISTINCT FROM NULL -- false NULL IS DISTINCT FROM 'test' -- true 'a' IS DISTINCT FROM 'b' -- true Пригодится в аудитах изменений, UPSERT-логике, ETL и триггерах, где важно понять: значение реально изменилось или нет. 🔥 Оператор, который убирает большое количество багов при работе с NULL. ➡️ SQL Ready | #совет

IT мероприятия 🤘 Всё самое интересное для карьеры в IT: митапы, хакатоны, конференции, стажировки и обучение. Подписывайся 🤘 1. Москва 2. Санкт-Петербург 3. Для стажеров и студентов

📂 Напоминалка по генерации уникальных ID в SQL и распределённых системах! Например, Auto-Increment подходит для простых SQL-проектов, где одна база данных управляет последовательностью записей, а Snowflake/UUID чаще используют в высоконагруженных системах с микросервисами, где требуется генерация ID без единой точки отказа. На картинке — 5 основных подходов к созданию уникальных идентификаторов. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

👍 Годная статья вышла на Хабре: «Шардированный не значит распределённый, что важно знать, когда PostgreSQL становится мало»! В этой статье: • Объясняется разница между шардированным PostgreSQL и настоящими распределёнными СУБД; • Разбирается, почему Citus и похожие решения не дают полноценные ACID-гарантии для multi-shard транзакций; • Показывается, как работают 2PC, distributed snapshot и уровни изоляции транзакций; • На примерах объясняются проблемы consistency и eventual consistency в распределённых системах; 🔊 Продолжай читать на Habr! ➡️ SQL Ready | #статья

DEFERRABLE constraints — проверяй связи в конце транзакции, а не после каждой строки! Иногда данные нужно вставить в несколько связанных таблиц внутри одной транзакции, но порядок операций временно нарушает внешний ключ. BEGIN; INSERT INTO payments (id, order_id) VALUES (1, 100); INSERT INTO orders (id) VALUES (100); COMMIT; Обычный FOREIGN KEY проверяется сразу, поэтому первый INSERT упадёт, если заказа 100 ещё нет. DEFERRABLE INITIALLY DEFERRED переносит проверку ограничения на момент COMMIT, поэтому база смотрит не на промежуточное состояние, а на итог транзакции. SET CONSTRAINTS ALL IMMEDIATE; При необходимости проверку можно принудительно выполнить раньше прямо внутри транзакции. Это полезно при сложных импортах, циклических связях, миграциях и переносе данных между системами, где временный неправильный порядок вставки допустим, но финальное состояние должно быть строго консистентным. 🔥 Фишка в том, что ты не отключаешь целостность данных, а просто переносишь момент проверки. ➡️ SQL Ready | #совет

🐱 PostgreSQL Cheat Sheet — удобная шпаргалка по PostgreSQL! Этот репозиторий собрал самые важные команды и конструкции PostgreSQL в одном месте. Здесь можно быстро вспомнить синтаксис запросов, работу с таблицами, индексами, представлениями, функциями, транзакциями и др. Такая шпаргалка особенно полезна во время работы или подготовки к собеседованию. Оставляю ссылочку: GitHub 📱 ➡️ SQL Ready | #репозиторий

В PostgreSQL уникальность можно проверять не для всей таблицы, а только для части строк! Допустим, у вас есть мягкое удаление пользователей: SELECT email, deleted_at FROM users; После удаления запись остаётся в таблице, но появляется дата удаления. Обычный уникальный индекс создаст проблему: CREATE UNIQUE INDEX users_email_uniq ON users (email); Теперь пользователь не сможет зарегистрироваться повторно с тем же email даже после удаления старого аккаунта. Решение — частичный уникальный индекс: CREATE UNIQUE INDEX users_active_email_uniq ON users (email) WHERE deleted_at IS NULL; Теперь PostgreSQL будет проверять уникальность только среди активных пользователей. Удалённые записи перестают участвовать в проверке. Точно так же можно хранить: CREATE UNIQUE INDEX one_draft_per_user ON posts (user_id) WHERE status = 'draft'; В этом случае у пользователя может быть сколько угодно опубликованных статей, но только один черновик одновременно. 🔥 Полезный инструмент для ограничений, которые обычно пытаются реализовать через триггеры или код приложения. ➡️ SQL Ready | #совет