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

🖥 SCD2 — хранение истории изменений в таблицах! При прямом UPDATE данные теряют историю: невозможно корректно восстановить состояние сущности на дату или отследить момент изменения. Сегодня в гайде:

• Как моделировать версионные данные через valid_from / valid_to; • Как корректно закрывать предыдущую версию и создавать новую; • Как получать актуальное состояние и исторические срезы без дополнительной логики.

SCD Type 2 хранит каждое изменение как отдельную версию строки с фиксированным интервалом актуальности. ➡️ SQL Ready | #гайд

Слили в телеграмм тонны инфы и отсортировали по каналам 🖥 Курсы & GitHub — 1579ГБ ⌨️ Python — 955ГБ 🤒 OSINT — 315ГБ ☁️ Хакинг & ИБ — 756ГБ 🙃 Linux & Bash — 459ГБ 😦 Работа в IT — 778ГБ 🖥 Общий архив — 2346ГБ ➡️ Практические инструкции, курсы, книги и инструменты.

😎 Сodedokode/pasta — теория + задачи на практике! Репозиторий с понятным и структурированным разбором баз данных на русском языке. Здесь разобраны ключевые концепции SQL для MySQL и PostgreSQL, есть примеры запросов и задачи для самостоятельной работы. Отлично подходит для укрепления базы и подготовки к собеседованиям.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

LEFT JOIN и WHERE — классическая ловушка с NULL! LEFT JOIN используют, когда нужно сохранить строки из левой таблицы, даже если в правой нет совпадений. Но одно неверное условие в WHERE — и LEFT JOIN незаметно превращается в INNER JOIN. Таблицы:

users(id, email)
orders(id, user_id, amount)

Нужно получить всех пользователей и их заказы (если есть):

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id;

Если у пользователя нет заказов, поля из orders будут NULL — это ожидаемое поведение LEFT JOIN. Теперь типичная ошибка:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.amount > 100;

Условие в WHERE отфильтровывает строки, где o.amount IS NULL. В результате пользователи без заказов исчезают, и запрос фактически работает как INNER JOIN. Правильный вариант — переносить условия на правую таблицу в ON:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
   AND o.amount > 100;

Теперь: пользователи без заказов остаются в результате, фильтрация применяется только к связанным строкам orders. Если же логика действительно требует убрать пользователей без заказов, тогда честнее писать INNER JOIN:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.amount > 100;

Так намерение запроса читается однозначно. 🔥 Условия в WHERE применяются после JOIN и могут уничтожить строки с NULL. Условия в ON влияют только на логику связывания таблиц. ➡️ SQL Ready | #практика

⚡ Повысить производительность СУБД или сократить расходы на IT-инфраструктуру? Не нужно выбирать. Selectel расскажет и покажет, как найти баланс на примере собственного сервиса. Подключайтесь к бесплатному вебинару для тех, кто работает с базами данных 🗓 5 февраля, 12:00 📍 Онлайн Вы узнаете: - как работают базы данных на выделенном облачном сервере, - какие особенности архитектуры позволяют повысить производительность сервиса в 10 раз и получить до 1,5 млн IOPS и 7000 Мб/c в облаке, - как клиентам Selectel удается экономить до 47% на IT-инфраструктуре. Регистрируйтесь по ссылке: https://slc.tl/27v33 👉 Чтобы не пропустить новые мероприятия, воркшопы и бесплатные курсы Selectel, подписывайтесь на @selectel_events Реклама. АО "Селектел". erid:2W5zFJj73Gc

❤️ AlgoTree — понятные объяснения алгоритмов, деревьев и графов! Этот сайт помогает анализировать структуры данных: деревья, графы, обходы и множество другого. Здесь нет решений задач или подготовкой к собеседованиям, упор именно на понимание того, как и почему всё устроено. Материал подается последовательно и концептуально, поэтому хорошо подходит даже новичкам. 📌 Оставляю ссылочку: algotree.org ➡️ SQL Ready | #ресурс

🖥 Ищем пересекающиеся бронирования! В системах бронирования одна из частых ошибок - это пересечение интервалов, когда один и тот же ресурс оказывается занят сразу несколькими пользователями. Сегодня в задаче:

• Сравним бронирования одного ресурса между собой, не создавая дубликатов; • Проверим пересечение временных интервалов с помощью канонического условия; • Получим список конфликтующих бронирований, которые система должна блокировать.

Это базовый инструмент контроля данных в системах бронирования, календарях, слотах доставки и любых сервисах с ограниченными ресурсами. ➡️ SQL Ready | #задача

Как получить «последнюю запись на группу»? Очень частая задача - взять последнюю запись на пользователя, заказ, сущность. Многие делают это с ROW_NUMBER(), хотя Postgres умеет проще:

SELECT DISTINCT ON (user_id) *
FROM orders
ORDER BY user_id, created_at DESC;

DISTINCT ON оставляет первую строку в рамках группы, а порядок задаётся через ORDER BY:

ORDER BY user_id, created_at DESC

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

ORDER BY user_id, created_at DESC, id DESC

Если нужно выбрать конкретные поля и избежать SELECT *, просто укажите нужные колонки:

SELECT DISTINCT ON (user_id)
       user_id, id, created_at
FROM orders
ORDER BY user_id, created_at DESC, id DESC;

Выражения из DISTINCT ON (...) обязаны быть левым префиксом ORDER BY, иначе Postgres выдаст ошибку. 🔥 Такой запрос часто читается проще, чем ROW_NUMBER(), и при подходящем индексе (user_id, created_at DESC, id DESC) может давать отличный план выполнения. ➡️ SQL Ready | #совет

Секрет, который делит январь на «до» и «после» в карьере. В январе есть два типа соискателей:

99% — обновляют резюме, рассылают его в 100 компаний и ждут. Они получают тишину или вежливые отказы. 1% — используют «окно возможностей». Они знают, что мало просто найти вакансии. Нужно пройти так, чтобы рекрутер не мог вас пропустить.

Разница не в опыте. Разница в методе. Мы в @mathcareer — про метод. Мы не даём «советы», а разбираем систему: как читать вакансию между строк, что писать в сопроводительном письме, которое откроет двери, и как вести переговоры. Хотите перейти из 99% в 1%? 👉 Всё уже разложено по полочкам здесь: https://t.me/+v5AE1DRA7L04MGVi

🖥 Поиск дубликатов и ранжирование данных! Шпаргалка по оконным функциям и агрегатам для нумерации строк, поиска и анализа дубликатов, ранжирования результатов и аккуратного удаления лишних записей. Используется при очистке данных, аналитических запросах, построении рейтингов и подготовке данных к миграциям и отчётности. ➡️ SQL Ready | #шпора

Настроил чат-бота за пару часов → заработал 9 000₽. Просто представь, кто-то стоит в очереди на маршрутку в 8 утра чтобы успеть на “любимую” работу. А кто-то за 3-4 часа делает чат-бота со своего ноута без привязки ко времени. Разница в зарплате: 200 тысяч. И нет — не надо ничего программировать. Зачем грузить мозги кодом, если можно собрать чат-бота для бизнеса на конструкторе. Без опыта. За 3-4 часа. 💡 Суть проста: Берёшь клиента → Собираешь бота по шаблону → Наставник всё проверяет → Сдаёшь работу и получаешь деньги. В первый месяц обычно выходят на доход 50–80 тыс ₽/мес, а с опытом от 180 тыс ₽ и выше. Легко совмещается с работой, учёбой, рыбалкой, семейными хлопотами… график устанавливаешь самостоятельно. Всё, что нужно для старта — запустить бота 👉 @other_digital_bot Там пошаговый план как стартануть и гайд по клиентам. До 26 января вход бесплатный.

💡 На Хабре вышла мега годная статья: «Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99%»! В этой статье: • О системе обработки огромного потока форм — от поиска до подачи объявлений; • Подробно объясняется, зачем команде нужен уровень надёжности SLI 99.99%; • Описаны оригинальные подходы к версионированию данных, изоляции изменений; • Приводятся реальные схемы работы с SQL/NoSQL, кэшами и стратегиями graceful degradation при отказах.

🔊 Продолжайте читать на Habr!

➡️ SQL Ready | #статья

Знали, что агрегаты можно фильтровать без CASE и подзапросов? Многие пишут COUNT(CASE WHEN ...), хотя в SQL (например, в PostgreSQL) есть более декларативный способ - FILTER. Фильтрация применяется к агрегатной функции, а не ко всей выборке:

COUNT(*) FILTER (WHERE status = 'paid')

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

COUNT(*) FILTER (WHERE status = 'failed')

Оптимизатор обычно сводит такой запрос к линейному плану. FILTER работает не только с COUNT, но и с другими агрегатами:

SUM(amount) FILTER (WHERE status = 'paid')

🔥 FILTER выразит намерение напрямую: агрегат считает только нужные строки, без лишней логики. ➡️ SQL Ready | #совет

Изоляция рунета ближе, чем ты думаешь

Loading … ██████████████] 99%

Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.

Email должен быть уникальным только для активных пользователей? Большинство реализуют это проверками в коде, SELECT перед INSERT, транзакциями или триггерами. PostgreSQL умеет делать это на уровне индекса:

INSERT INTO users (email) VALUES ('a@b.com');

Сработает, если активного пользователя с таким email ещё нет:

UPDATE users SET deleted_at = now() WHERE email = 'a@b.com';

Теперь email снова можно использовать для активных, без физического удаления строк. 🔥 Partial UNIQUE index — отличный способ фиксировать правила прямо в PostgreSQL. ➡️ SQL Ready | #совет

🚀 Yandex B2B Tech запускает сервис Managed Sharded PostgreSQL для горизонтального масштабирования PostgreSQL PostgreSQL — самая популярная open-source СУБД, которой сегодня пользуются 55,6% профессиональных разработчиков. Но одна из главных её ограничений — отсутствие встроенного горизонтального масштабирования, что критично при обработке больших объемов данных. Yandex B2B Tech решила эту задачу, запустив сервис , который позволяет шардировать PostgreSQL — то есть распределять данные по нескольким серверам. Это ускоряет работу систем, снижает риски и сокращает время вывода продуктов на рынок в 3-4 раза. Технология уже проверена в реальных проектах Яндекса, таких как Яндекс ID, Яндекс Пэй и Едадил, а также успешно используется внешними клиентами. Managed Sharded PostgreSQLдоступен на облачной платформе Yandex Cloud и помогает банкам и ритейлерам обрабатывать миллионы транзакций быстрее и надежнее. Подробнее — ссылка

👍 DataLemur — задачи для практики и подготовки к собеседованиям! На сайте собраны вопросы разного уровня сложности: от базовых запросов до задач с JOIN, GROUP BY, подзапросами и оконными функциями. Формат ориентирован на реальные кейсы, такие задачи часто встречаются в работе и на собеседованиях. Удобный ресурс, чтобы закрепить знания. 📌 Оставляю ссылочку: datalemur.com ➡️ SQL Ready | #ресурс