ar
Feedback
SQL Academy: всё о реляционных БД и SQL

SQL Academy: всё о реляционных БД и SQL

الذهاب إلى القناة على Telegram

По всем вопросам и коммерческим предложениям писать @LadanovNick Купить рекламу: https://telega.in/c/sqlacademyofficial Чат студентов SQL Academy https://t.me/sqlacademyorg

إظهار المزيد

📈 نظرة تحليلية على قناة تيليجرام SQL Academy: всё о реляционных БД и SQL

تُعد قناة SQL Academy: всё о реляционных БД и SQL (@sqlacademyofficial) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 11 363 مشتركاً، محتلاً المرتبة 10 911 في فئة التكنولوجيات والتطبيقات والمرتبة 57 339 في منطقة روسيا.

📊 مؤشرات الجمهور والحراك

منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 11 363 مشتركاً.

بحسب آخر البيانات بتاريخ 27 يونيو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 173، وفي آخر 24 ساعة بمقدار 1، مع بقاء الوصول العام مرتفعاً.

  • حالة التحقق: غير موثّقة
  • معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 17.59‎%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً N/A‎% من ردود الفعل نسبةً إلى إجمالي المشتركين.
  • وصول المنشورات: يحصل كل منشور على متوسط 1 997 مشاهدة. وخلال اليوم الأول يجمع عادةً 0 مشاهدة.
  • التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 16.
  • الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل sql, строка, индекс, auto_increment, created_at.

📝 الوصف وسياسة المحتوى

يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
По всем вопросам и коммерческим предложениям писать @LadanovNick Купить рекламу: https://telega.in/c/sqlacademyofficial Чат студентов SQL Academy https://t.me/sqlacademyorg

بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 28 يونيو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.

11 363
المشتركون
+124 ساعات
+497 أيام
+17330 أيام
أرشيف المشاركات
📕 Автоматизация процессов в Битрикс24 без кода для администраторов и специалистов Битрикс24, менеджеров и владельцев бизнеса
📕 Автоматизация процессов в Битрикс24 без кода для администраторов и специалистов Битрикс24, менеджеров и владельцев бизнеса На открытом уроке 9 июня в 19:00 мск мы погрузимся в тонкости работы с готовыми инструментами автоматизации Битрикс24.  📗 На вебинаре разберём: 1. 3 рабочих способа автоматизации без кода; 2. Готовые сценарии для продаж, маркетинга, CRM, и не только; 📘 В результате на практике разреберетесь в готовых инструментах и пошаговых алгоритмах автоматизации Битрикс24 без кода и изучите кейсы из реального бизнеса (например, "Как автоматизация сэкономила 200+ часов"). 👉 Регистрация и подробности о курсе Интегратор Битрикс24: https://otus.pw/27jf/?erid=2W5zFJeStJc  Все участники открытого урока получат скидку на курс "Интегратор Битрикс24", Чек-лист «10 процессов, которые нужно автоматизировать в первую очередь» и Шаблоны роботов для Битрикс24 Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

WINDOW-функция NTILE(): делим пользователей на квартели 📊 На собеседованиях любят задачу «раскидай пользователей по квартиля
WINDOW-функция NTILE(): делим пользователей на квартели 📊 На собеседованиях любят задачу «раскидай пользователей по квартилям по количеству покупок». NTILE() решает её одной строкой, без подзапросов и циклов в приложении. 1️⃣ Что такое NTILE() Оконная функция, которая разбивает отсортированный набор строк на N равных «коробок» (tiles).

NTILE(N) OVER (PARTITION BY … ORDER BY …)
🔹 N — число групп (4 = квартели). 🔹 PARTITION BY (необязательно) — создаёт независимые группы (например, по стране). 🔹 ORDER BY — признак, по которому сортируем и считаем ранг. 2️⃣ Классический пример: 4 квартиля по количеству заказов

SELECT
    user_id,
    orders_count,
    NTILE(4) OVER 
      (ORDER BY orders_count DESC) AS quartile
FROM user_stats
ORDER BY orders_count DESC;
🔹 Пользователи с наибольшим orders_count попадают в quartile = 1, а с наименьшим — в quartile = 4. 🔹 Если строк не делится поровну, верхние группы получат на 1 запись больше (MySQL делит «сверху»). 3️⃣ Квартели внутри каждой страны

SELECT
    country,
    user_id,
    orders_count,
    NTILE(4) OVER (
        PARTITION BY country
        ORDER BY orders_count DESC
    ) AS quartile
FROM user_stats;
Теперь каждый блок «страна» делится на свои 4 части — удобно для локальных лидеров. 4️⃣ Как использовать результат 🔹Маркетинг: таргетировать акции только quartile = 4 (самые неактивные). 🔹Аналитика: сравнить средний чек между квартилями. 🔍 Потренируйтесь Откройте готовый плейграунд, запустите NTILE(4) и поэкспериментируйте с разным числом групп. 👉 https://sqlplayground.app/sandbox/683ef210cb9fcbe8d3db3a9eИтог 🔹NTILE(N) быстро делит данные на равные сегменты. 🔹Работает вместе с PARTITION BY и любой сортировкой. 🔹Незаменим при сегментации пользователей, товаров или чеков.

📕 Сравнение индексации в PostgreSQL и ClickHouse для разработчиков, администраторов баз данных, инженеров и аналитиков данны
📕 Сравнение индексации в PostgreSQL и ClickHouse для разработчиков, администраторов баз данных, инженеров и аналитиков данных На открытом уроке 3 июня в 20:00 мск мы обсудим различия в механизмах индексации между PostgreSQL и ClickHouse.  📗 На вебинаре разберём: 1. Основы и сравнение производительности разных подходов к индексации; 2. Для каких сценариев распространено использование этих подходов; 📘 В результате на практике разберете и сравните подходы, производительность и архитектуру индексации PostgreSQL и ClickHouse. 👉 Регистрация и подробности о курсе ClickHouse для инженеров и архитекторов БД: https://tglink.io/391a735e96ea?erid=2W5zFFzAoHr Все участники открытого урока получат скидку на курс "ClickHouse для инженеров и архитекторов БД" Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🤫 Хотите узнать как сделать связку разработчик+аналитик SQL еще эффективнее? 🔥 Открыт набор на онлайн-курс “SQL для аналити
🤫 Хотите узнать как сделать связку разработчик+аналитик SQL еще эффективнее? 🔥 Открыт набор на онлайн-курс “SQL для аналитиков и разработчиков”, где мы научим вас продвинутым аспектам работы с реляционными базами данных, улучшить навыки работы с SQL-запросами, понять принципы нормализации баз данных.  Что будет на курсе? Основы реляционных баз данных, включая ER-диаграммы и компоненты БД Практику работы с несколькими популярными СУБД (PostgreSQL, SQL Server, MySQL, Oracle, SQLite) Базовый и продвинутый синтаксис SQL-запросов, включая SELECT, JOIN, агрегатные функции, оконные функции и другие Практику с применением индексов, триггеров, хранимых процедур и функций для оптимизации работы с данными Знание принципов транзакций и их роли в обеспечении целостности данных Практику оптимизации производительности запросов и управление большими объемами данных Знания особенностей работы с JSON, геоданными и полнотекстовым поиском в разных СУБД. 📈 Присоединяйтесь на курс и повысьте свой уровень в знании SQL: https://tglink.io/0267f993ac06?erid=2W5zFFv4z7S Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

LIMIT + OFFSET и «вечная прокрутка»: как делают Instagram-ленты 📜➡️ Зачем знать? На собеседованиях часто просят: «Сделай API
LIMIT + OFFSET и «вечная прокрутка»: как делают Instagram-ленты 📜➡️ Зачем знать? На собеседованиях часто просят: «Сделай API, чтобы лента грузилась порциями». Понимание пагинации важно и для новичков — вы сможете писать быстрые, масштабируемые запросы. ──────────────────────── 1️⃣ Классический способ — LIMIT + OFFSET

-- страница 3, по 20 записей
SELECT *
FROM posts
ORDER BY created_at DESC
LIMIT 20 OFFSET 40;
Работает просто, но есть три проблемы: 🔹 OFFSET N сначала пропускает N строк → чем дальше, тем медленнее. 🔹 Если за время прокрутки добавятся новые посты, пользователь увидит дубликаты или пропуски. 🔹При больших значениях OFFSET сервер читает тысячи строк зря. 2️⃣ Key-set pagination (a.k.a. «лента без дыр») Идея: вместо «пропустить N» передаём последний id/дату уже загруженной записи и берём следующие сверху.

-- первый запрос (стартовая лента)
SELECT *
FROM posts
ORDER BY created_at DESC
LIMIT 20;

-- фронт получает последнюю дату 
→ next_cursor = '2025-05-26 10:15:00'

-- второй запрос (следующая порция)
SELECT *
FROM posts
WHERE created_at < '2025-05-26 10:15:00'
ORDER BY created_at DESC
LIMIT 20;
Плюсы: ✅ Нет медленного OFFSET — используется индекс по created_at. ✅ Новые посты не «вставляются» в уже просмотренную часть, дубликатов нет. ✅ Маркер-курсор можно прятать в URL или JSON‐ответе. 3️⃣ Что передавать в качестве курсора? 🔹 Авто-инкремент id — легко, но если бывают «дыры» (удаления) — используйте < id. 🔹Дата/время — удобно, но в редких случаях возможны совпадения секунд. Можно добавить второй критерий:

WHERE (created_at < :cursor_date)
   OR (created_at = :cursor_date AND id < :cursor_id)
4️⃣ Советы и грабли ⚠️ 🔹Создайте индекс (created_at DESC) или (created_at, id) — иначе даже key-set будет сканировать всю таблицу. 🔹Никогда не показывайте номер страницы пользователю, если используете key-set: курсор — это дата/ID, а не «страница 5». 🔹Для поиска по разным фильтрам (например, user_id) добавляйте их в индекс (user_id, created_at). ✅ Итог 🔹LIMIT + OFFSET подходит для админ-таблиц или маленьких данных. 🔹Для «бесконечных» лент используйте key-set pagination: быстрее, без дубликатов, идеально для мобильных фидов в духе Instagram/ТикТок. Потренируйтесь: создайте таблицу posts, сгенерируйте 100 000 строк, сравните скорость OFFSET 90000 и key-set. Результат удивит! 🚀

❓Хотите овладеть Spark на профессиональном уровне? Приглашаем дата-инженеров 26 мая в 20:00 на открытый урок «Spark в Kuberne
❓Хотите овладеть Spark на профессиональном уровне? Приглашаем дата-инженеров 26 мая в 20:00 на открытый урок «Spark в Kubernetes». На занятии мы рассмотрим особенности и варианты запуска Spark в Kubernetes. 🔊 Вебинар проведет Вадим Заигрин, Team Lead команд инженеров данных на разных проектах. Продолжить освоение инструментов дата-инжиниринга вы сможете на онлайн-курсе «Spark Developer» от OTUS. Воспользуйтесь велком скидкой по промокоду Early_Spark_5 ➡️ Ссылка для регистрации: https://tglink.io/a013417c08ba?erid=2W5zFHj7gJU #реклама О рекламодателе

CASE в ORDER BY: сортируем по условию 🔄 Иногда нужно показать записи не просто «по алфавиту» или «по дате», а сначала важные
CASE в ORDER BY: сортируем по условию 🔄 Иногда нужно показать записи не просто «по алфавиту» или «по дате», а сначала важные, потом второстепенные. В MySQL (и в SQL вообще) это делается через выражение CASE прямо в ORDER BY. 💡 Зачем знать? Вопрос часто звучит на собеседованиях: «Как вывести VIP‑клиентов сверху, а остальных — по имени?» Умение написать условную сортировку показывает, что вы понимаете SQL‑движок, а не только копируете примеры. 🔹 Базовый пример: VIP‑клиенты выше остальных

SELECT name, is_vip
  FROM customers
  ORDER BY 
    CASE WHEN is_vip = 1 THEN 0 ELSE 1 END,
    name; 
    -- внутри групп сортируем по алфавиту
▶️ CASE возвращает 0 для VIP, 1 — для всех остальных. ▶️ В порядке сортировки 0 идёт раньше 1, поэтому VIP‑ы будут первыми 🔹Сложнее: приоритеты A > B > C → остальные

SELECT name, status
FROM orders
ORDER BY CASE status
    WHEN 'A' THEN 0
    WHEN 'B' THEN 1
    WHEN 'C' THEN 2
        ELSE 3
    END,
    created_at DESC;
▶️ Сначала все со статусом A, потом B, затем C, затем остальные. ▶️ Внутри каждой группы — свежие заказы выше (по дате). Типичные ошибки ⚠️ 1️⃣ NULL‑ы: если столбец может быть NULL, добавьте явную проверку

CASE WHEN col IS NULL THEN …
2️⃣ Числа вместо строк: не забывайте, что CASE должен возвращать однотипные значения (в примерах — всегда INT). 3️⃣ Производительность: выражение в ORDER BY отключает использование индекса. Для больших таблиц можно создать сгенерированный столбец с тем же CASE и проиндексировать его.

ALTER TABLE customers
  ADD vip_sort TINYINT AS (CASE WHEN is_vip = 1 THEN 0 ELSE 1 END) STORED,
  ADD INDEX (vip_sort);
Итоги ✅ 🔸CASE в ORDER BY даёт гибкую условную сортировку без подзапросов. 🔸Легко расставить приоритеты: VIP, скидки, статусы… 🔸Следите за NULL‑ами и индексацией при больших объёмах.

Системная аналитика | DWH. Работа в IT не только для программистов😉 Привет! Меня зовут Арина и я системный аналитик DWH в кр
Системная аналитика | DWH. Работа в IT не только для программистов😉 Привет! Меня зовут Арина и я системный аналитик DWH в крупном ритейле. Тебе интересна сфера IT? А работа с данными, бизнесом и разработкой?  На своем канале я делюсь своим опытом в IT, рассказываю, как начать карьеру аналитика и какие направления для развития существуют. Обсуждаем: - системный (и не только) анализ в IT - делимся инсайтами по работе с данными и актуальными трендами в отрасли - говорим про зарплаты Давайте анализировать вместе💅! Подпишись на Системная аналитика | DWH Реклама. Павлова А.О. ИНН 027722774802.

🚀 Мы запускаем Python Academy! 🚀 Python — это ключ к аналитике, автоматизации и быстрой разработке. Мы собрали материал, который поможет заложить прочный фундамент и сразу перейти к практике. 🐍💼 Что внутри: 1️⃣ стартуем в формате «Ранний доступ» — уроки уже открыты и будут регулярно пополняться; 2️⃣ практические задания после каждого модуля, чтобы теория превращалась в навык; 3️⃣ приятные сюрпризы и новые фичи впереди! 🎁 💡 Основной контент и задания — бесплатно. Учитесь без ограничений и прокачивайте навыки вместе с нами. Хотите ещё глубже? Подключайте Премиум, чтобы решать задачи с реальных собеседований в топ-IT-компаниях и получать расширенные возможности курса. 🔥 В честь запуска действует скидка 70 % по промокоду IAMFIRST. Перейти к курсу Python Academy → https://python-academy.org/ Чтобы не пропустить обновления и бонусы, присоединяйтесь к нашему Telegram-каналу 👉 https://t.me/pythonacademyofficial Спасибо, что растёте вместе с SQL Academy — и теперь с Python Academy. Ваши успехи — наша радость! 💙

Если вы размышляете, как усилить своё резюме, наш совет — освойте SQL. Это язык, который помогает извлекать ценную информацию
Если вы размышляете, как усилить своё резюме, наш совет — освойте SQL. Это язык, который помогает извлекать ценную информацию из массивов данных. Познакомиться с инструментом можно на бесплатном курсе «Введение в SQL и работу с базой данных». За 5 занятий вы научитесь создавать, редактировать и обновлять базы данных, сделаете свои первые запросы и отчёты. Курс будет полезен даже тем, кто пока не собирается становиться аналитиком. Научитесь применять SQL в своих задачах — с ним вы сможете больше – https://netolo.gy Реклама. ООО "Нетология". ИНН 7726464125 Erid: 2VSb5yHvD9z

AUTO_INCREMENT в MySQL: как работает, можно ли переопределить и сбросить счётчик? 🔢 💬 Почему важно Вопрос про AUTO_INCREMEN
AUTO_INCREMENT в MySQL: как работает, можно ли переопределить и сбросить счётчик? 🔢 💬 Почему важно Вопрос про AUTO_INCREMENT регулярно всплывает на собеседованиях: «почему ID прыгают через 5?», «как начать нумерацию с 1000?», «можно вернуть счётчик обратно?». Разберёмся на практике. 🔹 Что делает AUTO_INCREMENT При каждой вставке (`INSERT`) MySQL берёт текущее значение счётчика, увеличивает его на 1 и записывает в колонку.

CREATE TABLE users (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100)
);
🔹 Как задать стартовое значение Нужно указать AUTO_INCREMENT = n при создании или изменить уже существующую таблицу:

-- сразу при создании
CREATE TABLE orders (
  id INT AUTO_INCREMENT PRIMARY KEY,
  product VARCHAR(100)
) AUTO_INCREMENT = 1000;

-- позднее
ALTER TABLE orders AUTO_INCREMENT = 5000;
💡 Полезно, если хотите «красивые» ID или переносите старые данные. 🔹 Почему появляются «дырки» в нумерации 1. DELETE. Удалили строку с id = 5 → число 5 уже не вернётся. 2. ROLLBACK. Транзакция вставила id = 6 и откатилась — 6 пропадает. 3. Сбой сервера. MySQL резервирует диапазон ID в буфере; при крэше часть чисел «теряется». 🔹 Можно ли сбросить счётчик? Да, но осторожно.

ALTER TABLE users AUTO_INCREMENT = 1;
Условие: новое значение должно быть больше любого существующего id. Иначе получите ошибку или конфликт PK. 🛑 На проде почти никогда не делают — потеря сквозной уникальности мешает логам и внешним ссылкам. 🔹 Грабли и советы 1️⃣ Не используйте AUTO_INCREMENT как «количество строк» — после DELETE счётчик не отражает реальное число записей. 2️⃣ Храните ссылки на записи только по уникальным id, а не позициям. 3️⃣ Если важно отсутствие дырок (к примеру, номера чеков) — создавайте отдельную таблицу «генератор последовательностей» или используйте сериализацию в приложении. 📝 Итог 1️⃣ Начать с нужного числа — AUTO_INCREMENT = N. 2️⃣ Сбросить можно, но не ниже текущего максимума. 3️⃣ Пропуски после DELETE и ROLLBACK — нормальное поведение.

Зачем нужно секционирование в PostgreSQL? Поделимся с вами на открытом уроке «PostgreSQL и секционирование: разделяй и властв
Зачем нужно секционирование в PostgreSQL? Поделимся с вами на открытом уроке «PostgreSQL и секционирование: разделяй и властвуй!» от Otus. На уроке: 🔹 Разберем проблемы больших таблиц и как секционирование повышает производительность, упрощает обслуживание и масштабирование. 🔹 Изучим виды секционирования (по списку, диапазону, хэшу) и современный декларативный подход. ✅ Практические советы: лучшие практики, оптимизация запросов и как избежать частых ошибок при работе с секциями. Освойте секционирование и управляйте большими объемами данных в PostgreSQL эффективно! ⚠️ 3 из 5 компаний уже перешли с Oracle и MS SQL на PostgreSQL. Доля российских производителей СУБД на рынке выросла с 66% до 82% за год Сделайте ваши PostgreSQL-запросы молниеносными с помощью правильных индексов! Регистрация на урок 👇 https://otus.pw/8jRn/?erid=2W5zFJ7TCQp Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

CHECK-ограничения в MySQL: валидация прямо в таблице ✅ Когда вы хотите убедиться, что в таблицу попадают только корректные да
CHECK-ограничения в MySQL: валидация прямо в таблице ✅ Когда вы хотите убедиться, что в таблицу попадают только корректные данные — не всегда нужно писать сложную логику в приложении. Иногда достаточно встроенного механизма MySQL: ограничения CHECK. 🔹 Что такое CHECK? Это правило, которое автоматически проверяет значение в колонке при вставке (INSERT) или обновлении (UPDATE). Если правило нарушено — операция отменяется с ошибкой. Пример:

CREATE TABLE users (
  id INT PRIMARY KEY,
  age INT,
  CHECK (age >= 0 AND age <= 120)
);
Теперь нельзя вставить пользователя с возрастом -5 или 999 — MySQL просто не даст это сделать. Синтаксис CHECK 🔸 Можно добавлять при создании таблицы (CREATE TABLE) или позже (ALTER TABLE). 🔸 Можно использовать AND, OR, арифметику, сравнения, функции (с ограничениями). 🔸 Поддерживается в MySQL 8.0+. В старых версиях CHECK игнорировался (!). Пример с условием на строку:

CREATE TABLE products (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  category ENUM('book', 'game', 'toy'),
  price DECIMAL(10,2),
  CHECK (price >= 0)
);
Здесь мы запрещаем отрицательные цены. Добавление ограничения в существующую таблицу:

ALTER TABLE users
ADD CONSTRAINT chk_age CHECK (age >= 0 AND age <= 120);
Что произойдёт при нарушении?

INSERT INTO users (id, age) VALUES (1, -10);
-- ERROR 3819 (HY000): Check constraint 'chk_age' is violated.
⚠️ Важно помнить: 🔹CHECK срабатывает только для новых данных — старые строки не проверяются. 🔹Если значение NULL, правило обычно не нарушается (NULL считается «неизвестным» и не сравнивается напрямую). 🔹Ошибку можно перехватывать в приложении, чтобы сообщить пользователю. ✅ Когда стоит использовать CHECK: 🔹 Для ограничений: возраст, положительная цена, длина строки, формат (через LIKE или REGEXP). 🔹Когда хотите, чтобы в таблице «по умолчанию» всегда были только корректные данные. 🔹Чтобы упростить валидацию и сделать БД самодостаточной (например, при работе с внешними источниками данных).

Столкнулись с падением производительности базы данных? Не делайте резких движений: вы можете ухудшить ситуацию. Сначала нужно
Столкнулись с падением производительности базы данных? Не делайте резких движений: вы можете ухудшить ситуацию. Сначала нужно верно диагностировать причину проблемы. Возможно вы неправильно выбрали индексы, а быть может дело вообще в самой архитектуре БД – вариантов масса! На открытом вебинаре «Как ускорить работу и повысить надёжность PostgreSQL» вы узнаете: 🎯как обеспечить высокую производительность и отказоустойчивость базы данных 🎯как вовремя выявить деградацию производительности с помощью диагностики Вебинар проведёт Дмитрий Золотов, Kotlin-разработчик в «Яндексе». Приглашаем технических руководителей, админов БД, девопсов и разработчиков. Все участники получат в подарок видеоурок «Безопасность в PostgreSQL: защита данных, управление доступом и аудит» и скидку 7% на любой курс OTUS. 6 мая, 19:00 МСК Бесплатно Записаться - https://otus.pw/w04w/ Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: 2W5zFJpd2ji

NULL в SQL: зачем знать и как работать Что такое NULL? Это специальное значение «неизвестно / отсутствует». Оно не равно нулю
NULL в SQL: зачем знать и как работать Что такое NULL? Это специальное значение «неизвестно / отсутствует». Оно не равно нулю, пустой строке или 0 — это «ничего». Почему NULL может создать проблемы 🔹 Сравнение = NULL всегда возвращает FALSE → условия «теряют» строки. 🔹Агрегаты (`SUM`, `AVG`) игнорируют NULL → итоги оказываются заниженными. 🔹Деление на 0 вызывает ошибку, если предварительно не обработать значение. В MySQL есть три базовые функции, которые помогают держать ситуацию под контролем. 1️⃣ IFNULL(expr, alt) — поставить значение по умолчанию Возвращает alt, если expr равно NULL, иначе возвращает expr.

SELECT name,
       IFNULL(email, 'no-email@example.com') AS contact
FROM users;
Результат: вместо NULL-email выводится строка-заглушка. 2️⃣ COALESCE(expr1, expr2, …) — взять первое ненулевое Последовательно проверяет аргументы слева направо и возвращает первый, который не NULL.

SELECT name,
       COALESCE(email, phone, 'нет контактов') AS main_contact
FROM users;
Сценарий: если email отсутствует, берём phone; если и он NULL — выводим фразу «нет контактов». 3️⃣ NULLIF(a, b) — обнулить при равенстве Возвращает NULL, когда a = b, иначе возвращает a. Полезно, чтобы избежать деления на ноль.

SELECT revenue / NULLIF(orders_count, 0) AS avg_check
FROM shop_stats;
Если orders_count равен 0, деление не выполняется — результатом будет NULL вместо ошибки. Памятка 🔹Для проверок используйте IS NULL и IS NOT NULL, а не = NULL. 🔹Проверяйте, как агрегатные функции ведут себя с пропущенными данными. 🔹В формулах страхуйтесь NULLIF, чтобы не получить «division by zero». Запомните IFNULL, COALESCE и NULLIF — с ними работа с NULL становится предсказуемой и безопасной. 🚀

Как загнать IT-команду в ловушку? Очень просто: - полностью доверять все ключевые задачи двум единственным крутым специалиста
Как загнать IT-команду в ловушку? Очень просто: - полностью доверять все ключевые задачи двум единственным крутым специалистам - не развивать остальную команду: держать прочих сотрудников на одном и том же уровне - дождаться, пока асы разработки не выдержат нагрузки и уйдут - finita la comedia! Не дайте такому сценарию осуществиться. Приходите на открытый вебинар «Как руководителю развивать команду: структурируем компетенции и гибкие навыки сотрудников». Будет интересно: операционным директорам и IT-руководителям, менеджерам продуктов и проектов, тимлидам поддержки. - Вы разберётесь, как повысить эффективность вашей бизнес-единицы - Узнаете, как создать матрицу компетенций и составить индивидуальный план развития сотрудника - Поймёте, как развивать всех сотрудников, чтобы не зависеть от отдельных специалистов - Увидите, как подойти к развитию ваших сотрудников с точки зрения задач бизнеса Спикеры: Константин Кафтан, менеджер ИИ-продуктов в Wildberries Галина Баранова, COO в Altasales, продюсер бизнес-форума «Продажи.Главное» Бонус! Всем участникам – скидка 5% на любой курс и полезная инструкция «5 ключевых коммуникационных навыков для ИТ-команд» 23 апреля, 19:00 МСК, Бесплатно Записаться на событие - https://otus.pw/KZpn/?erid=2W5zFHw5cYG Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Тратите много времени на повторяющиеся SQL-запросы, выполняя рутинные задачи вручную? На бесплатном вебинаре, который пройдет
Тратите много времени на повторяющиеся SQL-запросы, выполняя рутинные задачи вручную?  На бесплатном вебинаре, который пройдет 22 апреля в 20:00, мы решим эту проблему и научим вас создавать и использовать хранимые процедуры для автоматизации процессов в SQL! https://otus.pw/sYDb/ Представьте, что вы можете автоматизировать эти задачи с помощью хранимых процедур в MS SQL Server и PostgreSQL, увеличив свою эфффективность. Больше не придется тратить на это лишние силы. Записывайтесь на урок, получайте практические навыки, а также скидку на большое обучение «SQL для разработчиков и аналитиков»: https://otus.pw/sYDb/ erid: 2W5zFGp9d2g

Часовые пояса в MySQL: как не запутаться и правильно хранить время? 🕒 Представьте: вы сохранили в базе данных время, когда п
Часовые пояса в MySQL: как не запутаться и правильно хранить время? 🕒 Представьте: вы сохранили в базе данных время, когда пользователь отправил сообщение, а позже оказалось, что для одного пользователя это "11:00", а для другого – "14:00". Почему так происходит? Дело в часовых поясах. 🌍 Что такое UTC? UTC (Coordinated Universal Time) – это универсальное мировое время, от которого отсчитываются все часовые пояса планеты. Это удобная точка отсчёта, которая не зависит от часового пояса вашего сервера или пользователей. ❗ Почему это важно? Если вы будете хранить данные в разных часовых поясах (например, местное время каждого пользователя), в базе данных появится хаос. Станет сложно сравнивать даты и время, а также понять, когда именно произошло событие. 🔹 Как правильно хранить время в MySQL? Правило простое: 1️⃣ Храните всё время в базе данных в формате UTC. 2️⃣ Конвертируйте его в местное время только тогда, когда показываете пользователю. Для хранения времени в MySQL можно использовать разные типы данных. Наиболее распространены TIMESTAMP и DATETIME. Давайте разберёмся, какой тип лучше выбрать. 🔹 Разница между типами TIMESTAMP и DATETIME 🔘 TIMESTAMP автоматически сохраняет данные в UTC и при чтении может автоматически конвертировать в текущий часовой пояс сервера. 🔘 DATETIME не имеет привязки к часовому поясу и хранит время ровно так, как вы его сохранили. Поэтому при использовании DATETIME нужно всегда явно указывать UTC-время. 🔹 Пример работы с UTC: ✅ Сохраняем текущее время в UTC:

INSERT INTO messages (sent_at)
VALUES (UTC_TIMESTAMP());
✅ Читаем данные и переводим в нужный пояс (например, для Москвы, +03:00)

SELECT sent_at, 
CONVERT_TZ(sent_at, '+00:00', '+03:00') AS sent_at_moscow
FROM messages;
🔹 Итоговые рекомендации: 1️⃣ Используйте TIMESTAMP для автоматического хранения данных в UTC. 2️⃣ Для ручного управления используйте тип DATETIME и всегда сохраняйте в UTC. 3️⃣ Переводите данные в локальное время только при отображении.

⏰Регистрируйся на вебинар 🔋 Миграция приложений с Oracle Apex, Oracle Forms на Postgres. На вебинаре расскажем как сохранить
⏰Регистрируйся на вебинар 🔋 Миграция приложений с Oracle Apex, Oracle Forms на Postgres. На вебинаре расскажем как сохранить команду разработчиков и перейти с Oracle Apex, Oracle Forms. • 10 лет за 5 минут как мы делали клон Oracle Apex/Forms/Reports на PostgreSQL • Разработка приложений с применением только SQL / plpgSQL • Oracle Apex на PostgreSQL на стероидах Visual Studio Code  • Пару слов об xDac for Postgres. Презентация XSQUARE – DAC for ORACLE 📌Обещаем технический вебинар, без слайдов и маркетинга. #реклама О рекламодателе erid: 2W5zFGkuXRi

Как хранить бинарные данные (BLOB) в MySQL? 🔒 BLOB (Binary Large Object) — это способ хранить двоичные данные (файлы, изобра
Как хранить бинарные данные (BLOB) в MySQL? 🔒 BLOB (Binary Large Object) — это способ хранить двоичные данные (файлы, изображения, документы и т.д.) прямо в базе MySQL. Однако есть нюансы, которые важно учитывать. 🔹 Виды BLOB: 1️⃣ TINYBLOB — до 255 байт 2️⃣ BLOB — до ~65 КБ 3️⃣ MEDIUMBLOB — до ~16 МБ 4️⃣ LONGBLOB — до ~4 ГБ 🔹 Когда стоит использовать BLOB? ✅ Для небольших файлов (например, аватары пользователей) ✅ Когда важно хранить всё в одной базе (цельность и транзакции) ✅ При отсутствии внешнего хранилища ⚠️ Большие файлы (видео, большие документы) лучше хранить вне БД, а в базе — только пути к ним. 🔹 Пример таблицы:

CREATE TABLE user_avatars (
  id INT AUTO_INCREMENT PRIMARY KEY,
  user_id INT NOT NULL,
  avatar MEDIUMBLOB NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
🔹 Вставка данных:

INSERT INTO user_avatars (user_id, avatar)
VALUES (123, LOAD_FILE('/path/to/avatar.png'));
Или передача через параметризованный запрос из приложения (PHP/Python), где двоичные данные вставляются напрямую. 🔹 Ограничения и подводные камни: 1️⃣ Большие BLOB замедляют запросы и увеличивают размер бэкапа 2️⃣ Нужны корректные настройки (max_allowed_packet, innodb_log_file_size и др.) 3️⃣ При блокировке таблицы с большим BLOB транзакции могут зависать дольше 4️⃣ Бэкапы и восстановление займут больше времени 🔹 Рекомендации: 1️⃣ Для больших файлов — отдельное хранилище (например, S3), а в БД только ссылки 2️⃣ При использовании BLOB — ограничивать максимальный размер файлов 3️⃣ Следить за правами (функция LOAD_FILE требует соответствующих привилегий) 4️⃣ Использовать кэширование (CDN), если часто выгружаете большие файлы