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

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?
Это специальное значение «неизвестно / отсутствует». Оно не равно нулю, пустой строке или 0 — это «ничего».

Почему NULL может создать проблемы
🔹 Сравнение = NULL всегда возвращает FALSE → условия «теряют» строки.
🔹Агрегаты (`SUM`, `AVG`) игнорируют NULL → итоги оказываются заниженными.
🔹Деление на 0 вызывает ошибку, если предварительно не обработать значение.

В MySQL есть три базовые функции, которые помогают держать ситуацию под контролем.

1️⃣ IFNULL(expr, alt) — поставить значение по умолчанию
Возвращает alt, если expr равно NULL, иначе возвращает expr.

SELECT name,
       IFNULL(email, '[email protected]') 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-команду в ловушку?

Очень просто:
- полностью доверять все ключевые задачи двум единственным крутым специалистам
- не развивать остальную команду: держать прочих сотрудников на одном и том же уровне
- дождаться, пока асы разработки не выдержат нагрузки и уйдут
- finita la comedia!

Не дайте такому сценарию осуществиться.
Приходите на открытый вебинар «Как руководителю развивать команду: структурируем компетенции и гибкие навыки сотрудников».

Будет интересно: операционным директорам и IT-руководителям, менеджерам продуктов и проектов, тимлидам поддержки.

- Вы разберётесь, как повысить эффективность вашей бизнес-единицы
- Узнаете, как создать матрицу компетенций и составить индивидуальный план развития сотрудника
- Поймёте, как развивать всех сотрудников, чтобы не зависеть от отдельных специалистов
- Увидите, как подойти к развитию ваших сотрудников с точки зрения задач бизнеса

Спикеры:
Константин Кафтан, менеджер ИИ-продуктов в Wildberries
Галина Баранова, COO в Altasales, продюсер бизнес-форума «Продажи.Главное»

Бонус! Всем участникам – скидка 5% на любой курс и полезная инструкция «5 ключевых коммуникационных навыков для ИТ-команд»

23 апреля, 19:00 МСК, Бесплатно

Записаться на событие - https://otus.pw/KZpn/?erid=2W5zFHw5cYG

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Тратите много времени на повторяющиеся SQL-запросы, выполняя рутинные задачи вручную? 
На бесплатном вебинаре, который пройдет 22 апреля в 20:00, мы решим эту проблему и научим вас создавать и использовать хранимые процедуры для автоматизации процессов в SQL! https://otus.pw/sYDb/

Представьте, что вы можете автоматизировать эти задачи с помощью хранимых процедур в MS SQL Server и PostgreSQL, увеличив свою эфффективность. Больше не придется тратить на это лишние силы.

Записывайтесь на урок, получайте практические навыки, а также скидку на большое обучение «SQL для разработчиков и аналитиков»: https://otus.pw/sYDb/

erid: 2W5zFGp9d2g

Часовые пояса в 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.

• 10 лет за 5 минут как мы делали клон Oracle Apex/Forms/Reports на PostgreSQL
• Разработка приложений с применением только SQL / plpgSQL
• Oracle Apex на PostgreSQL на стероидах Visual Studio Code 
• Пару слов об xDac for Postgres. Презентация XSQUARE – DAC for ORACLE

📌Обещаем технический вебинар, без слайдов и маркетинга.

#реклама
О рекламодателе
erid: 2W5zFGkuXRi

⏰Регистрируйся на вебинар

🔋 Миграция приложений с 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) — это способ хранить двоичные данные (файлы, изображения, документы и т.д.) прямо в базе 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), если часто выгружаете большие файлы