TGViewer
Channel Public Channel
SQL Ready | Базы Данных

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

@sql_ready

Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!

Cотрудничество: @energy_c

РКН: https://clck.ru/3QREBc
Subscribers
17.5K
Photos
1.4K
Videos
113
Links
765

Showing posts older than #1685 · Back to latest

Older Posts 16 shown
Post #1683 2.55K
💡 На Хабре вышла мега годная статья: «Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99%»!

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


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


➡️ SQL Ready | #статья
  • 👍 12
  • 🔥 8
  • 🤝 8
Post #1682 2.51K
Знали, что агрегаты можно фильтровать без 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 | #совет
  • 🔥 23
  • ❤ 12
  • 🤝 8
  • 👍 2
Post #1680 2.63K
  • 🔥 12
  • 👍 7
  • 🤝 7
  • ❤ 1
Post #1679 2.65K
  • 👍 10
  • 🔥 8
  • 🤝 7
  • ❤ 1
Post #1678 3K
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 | #совет
  • 👍 16
  • 🔥 7
  • 🤝 7
Post #1677 2.42K
🚀 Yandex B2B Tech запускает сервис Managed Sharded PostgreSQL для горизонтального масштабирования PostgreSQL

PostgreSQL — самая популярная open-source СУБД, которой сегодня пользуются 55,6% профессиональных разработчиков. Но одна из главных её ограничений — отсутствие встроенного горизонтального масштабирования, что критично при обработке больших объемов данных.

Yandex B2B Tech решила эту задачу, запустив сервис , который позволяет шардировать PostgreSQL — то есть распределять данные по нескольким серверам. Это ускоряет работу систем, снижает риски и сокращает время вывода продуктов на рынок в 3-4 раза.

Технология уже проверена в реальных проектах Яндекса, таких как Яндекс ID, Яндекс Пэй и Едадил, а также успешно используется внешними клиентами.

Managed Sharded PostgreSQLдоступен на облачной платформе Yandex Cloud и помогает банкам и ритейлерам обрабатывать миллионы транзакций быстрее и надежнее.

Подробнее — ссылка
CNews.ru Yandex B2B Tech поможет банкам и ритейлерам обрабатывать миллионы транзакций быстрее и надежнее - CNews Yandex B2B Tech запустила сервис для быстрого горизонтального масштабирования самой популярной опенсорсной базы данных...
  • ❤ 4
  • 👎 3
  • 👍 2
  • 🔥 2
Post #1676 2.48K
👍 DataLemur — задачи для практики и подготовки к собеседованиям!

На сайте собраны вопросы разного уровня сложности: от базовых запросов до задач с JOIN, GROUP BY, подзапросами и оконными функциями. Формат ориентирован на реальные кейсы, такие задачи часто встречаются в работе и на собеседованиях. Удобный ресурс, чтобы закрепить знания.

📌 Оставляю ссылочку: datalemur.com

➡️ SQL Ready | #ресурс
  • 🔥 11
  • 👍 8
  • 🤝 8
Post #1675 2.07K
Partial index по стабильному селективному срезу!

В PostgreSQL частичный индекс особенно эффективен, когда в запросах регулярно повторяется один и тот же селективный предикат WHERE, а цель — быстро получить последние N записей по времени.

Таблица:
audit_logs(id, service, level, created_at, payload JSONB)


Индекс под узкий сегмент:
CREATE INDEX idx_billing_errors
ON audit_logs (created_at DESC)
WHERE service = 'billing' AND level = 'error';


Меньший размер индекса снижает нагрузку на buffer cache, уменьшает вероятность bloat и объём фонового обслуживания, а операции с индексом требуют меньше ресурсов.

Запрос за последними ошибками за сутки:
SELECT id, created_at, payload
FROM audit_logs
WHERE service = 'billing'
AND level = 'error'
AND created_at > NOW() - INTERVAL '1 day'
ORDER BY created_at DESC
LIMIT 15;


Связка ORDER BY created_at DESC + LIMIT позволяет планировщику сделать Index Scan и остановиться рано, как только найдено нужное количество строк.

index-only scan возможен только если все нужные колонки читаются из индекса, и страницы таблицы помечены all-visible (visibility map).

Если вам действительно нужен index-only для части полей, можно использовать INCLUDE:
CREATE INDEX idx_billing_errors_top
ON audit_logs (created_at DESC)
INCLUDE (id)
WHERE service = 'billing' AND level = 'error';


Частичный индекс по JSONB boolean-предикату (когда совпадающих строк мало и условие повторяется):
CREATE INDEX idx_critical_errors
ON audit_logs (created_at DESC)
WHERE level = 'error'
AND payload @> '{"critical": true}';


И быстрый top-N:
SELECT id, service, created_at
FROM audit_logs
WHERE level = 'error'
AND payload @> '{"critical": true}'
ORDER BY created_at DESC
LIMIT 10;


🔥 Частичные индексы — простой и экономный инструмент для повторяемого узкого среза + быстрого top-N по времени.

➡️ SQL Ready | #практика
  • 🔥 11
  • ❤ 7
  • 👍 7
Post #1673 2.15K
❤️ Нашёл замечательную статью на Хабре: «Курс молодого бойца PostgreSQL»!

В этой статье:
• Автор шаг за шагом показывает, как использовать ключевые возможности PostgreSQL;
• Приводятся понятные примеры SQL-запросов с объяснением, когда и почему применять те или иные конструкции;
• Рассматриваются полезные трюки - преобразование типов, агрегации и работа с массивами;
• Все примеры можно сразу запускать.


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


➡️ SQL Ready | #статья
  • 👍 14
  • ❤ 9
  • 🔥 9
Post #1672 2.45K
IS NOT DISTINCT FROM - равенство без NULL!

Обычное сравнение через = ломается, если возможен NULL:
SELECT *
FROM users
WHERE email = 'admin@example.com';


Эта проверка никогда не вернёт строки с NULL, даже если логически они равны:
SELECT *
FROM users
WHERE email IS NOT DISTINCT FROM NULL;


IS NOT DISTINCT FROM считает NULL = NULL и работает как настоящее равенство:
sql
SELECT *
FROM users
WHERE (email, phone)
IS NOT DISTINCT FROM ('a@b.com', NULL);


Работает и для составных сравнений, без OR … IS NULL.

🔥 IS NOT DISTINCT FROM - способ сравнивать значения, когда NULL допустимое состояние, а не исключение.

➡️ SQL Ready | #совет
  • 👍 13
  • ❤ 8
  • 🔥 7
  • 👎 1
Post #1670 2.65K
📂 Напоминалка для работы с SQL JOIN!

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

На картинке — 4 самых используемых типа SQL JOIN, которые постоянно встречаются в рабочих запросах.

Сохрани, чтобы не забыть!

➡️ SQL Ready | #ресурс
  • ❤ 16
  • 👍 9
  • 🔥 7
Post #1665 2.83K
🖥 INDEX ONLY SCAN — когда SELECT не идёт в таблицу!

Когда в запросе нужны 2-3 конкретных поля, база может отдать их прямо из индекса, не трогая таблицу. Это особенно важно для тяжёлых таблиц, где каждый лишний lookup - потеря времени.

Сегодня в гайде:
• Как запрос выполняется только из индекса;

• Как убедиться, что таблица не читается (Heap Fetches: 0 в плане);

• Как проектировать индексы, чтобы покрывать SELECT полностью.


Покрывающий индекс устраняет table lookup, снижает I/O и делает чтение стабильным при росте данных.

➡️ SQL Ready | #гайд
  • 🔥 15
  • ❤ 8
  • 👍 6
  • 🤝 1
Post #1663 2.45K
☕️ Смотрите что нашел — Explainshell.

Вводишь любую команду в терминале, и он по частям объясняет, что делает каждая часть. Не просто man-ка, а понятный синтакс-анализ.

Особенно кайф для тех, кто работает в Linux/DevOps/CI среде и хочет разбираться, а не наугад копипастить из StackOverflow.

📌 Оставляю ссылочку: explainshell.com

➡️ SQL Ready | #ресурс
  • 👍 13
  • 🔥 9
  • 🤝 9
Post #1662 2.5K
EXPLAIN — узнаём, как СУБД реально выполняет ваш запрос!

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

Допустим, у нас есть запрос:
SELECT * FROM books WHERE author = 'Толстой';


Запускаем EXPLAIN, чтобы посмотреть план выполнения:
EXPLAIN SELECT * FROM books WHERE author = 'Толстой';


Если видим Table Scan или Seq Scan — это означает, что происходит полный просмотр таблицы. Такой способ может быть медленным, особенно при большом объёме данных.

Чтобы ускорить выполнение, создаём индекс:
CREATE INDEX idx_author ON books(author);


🔥 Теперь при повторном EXPLAIN запрос может использовать Index Scan, что значительно быстрее.

➡️ SQL Ready | #практика
  • 🔥 13
  • 👍 10
  • ❤ 8
Post #1660 2.35K
📂 Напоминалка по нормальным формам баз данных!

Например, 1NF требует атомарных значений, 2NF убирает частичные зависимости, а 3NF избавляет от транзитивных зависимостей.

На картинке — основные нормальные формы, которые полезны при проектировании SQL-баз данных.

Сохрани, чтобы не забыть!

➡️ SQL Ready | #ресурс
  • 🔥 13
  • 👍 9
  • 🤝 7
  • ❤ 1
Post #1659 2.3K
Согласованное чтение данных внутри одной транзакции!

Иногда несколько SELECT должны работать с одной и той же версией данных, даже если параллельно идут изменения.
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;


В PostgreSQL это фиксирует MVCC snapshot в момент первого statement внутри транзакции:
SELECT COUNT(*) FROM orders;


Все последующие SELECT читают один и тот же snapshot и не видят новые COMMIT из других сессий, при этом собственные изменения транзакции видны:
SELECT SUM(amount) FROM orders;


Это гарантирует согласованность результатов между запросами без блокировки пишущих транзакций:
COMMIT;


🔥 После COMMIT snapshot освобождается, транзакция завершается.

➡️ SQL Ready | #совет
  • ❤ 10
  • 🔥 9
  • 👍 8
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →