🔹 5 главных ошибок при работе с SQL, которые совершают даже опытные!
💡 SQL кажется простым, но даже профи допускают ошибки. Давай разберём 5 самых распространённых и как их избежать.
1️⃣ Забывать про NULL в условиях
❌ Ошибка:
Этот запрос не вернёт ничего, потому что NULL нельзя сравнивать с =.
✅ Правильно:
Используй IS NULL или COALESCE(email, '').
2️⃣ Не использовать индексы
Если таблица растёт, запросы могут замедлиться в разы!
✅ Решение: Создавай индексы для часто используемых полей:
⚡️ Ускоряет SELECT по email!
3️⃣ Использовать SELECT * везде подряд
❌ Так делать нельзя:
✅ Вместо этого выбирай только нужные колонки – это уменьшает нагрузку на базу:
4️⃣ Забывать про GROUP BY при агрегатных функциях
❌ Ошибка:
SQL выдаст ошибку, потому что не знает, как сгруппировать department.
✅ Правильно:
5️⃣ Не ограничивать выборку (LIMIT)
Если таблица огромная, запрос без LIMIT может перегрузить сервер.
✅ Добавь ограничение:
Теперь ты загружаешь только 100 последних записей.
🔥 Вывод:
✔️ Проверяй NULL правильно.
✔️ Используй индексы для ускорения.
✔️ Не выбирай лишние данные.
✔️ Не забывай GROUP BY при агрегатных функциях.
✔️ Добавляй LIMIT, если работаешь с большими таблицами.
❓ А какие ошибки SQL ты встречал в работе? Делись в комментариях!
#SQL #DML #ИТ #Оптимизация_SQL
#Ошибки_SQL
💡 SQL кажется простым, но даже профи допускают ошибки. Давай разберём 5 самых распространённых и как их избежать.
1️⃣ Забывать про NULL в условиях
❌ Ошибка:
SELECT * FROM users WHERE email = NULL;
Этот запрос не вернёт ничего, потому что NULL нельзя сравнивать с =.
✅ Правильно:
SELECT * FROM users WHERE email IS NULL;
Используй IS NULL или COALESCE(email, '').
2️⃣ Не использовать индексы
Если таблица растёт, запросы могут замедлиться в разы!
✅ Решение: Создавай индексы для часто используемых полей:
CREATE INDEX idx_users_email ON users(email);
⚡️ Ускоряет SELECT по email!
3️⃣ Использовать SELECT * везде подряд
❌ Так делать нельзя:
SELECT * FROM orders;
✅ Вместо этого выбирай только нужные колонки – это уменьшает нагрузку на базу:
SELECT order_id, amount FROM orders;
4️⃣ Забывать про GROUP BY при агрегатных функциях
❌ Ошибка:
SELECT department, AVG(salary) FROM employees;
SQL выдаст ошибку, потому что не знает, как сгруппировать department.
✅ Правильно:
SELECT department, AVG(salary)
FROM employees
GROUP BY department;
5️⃣ Не ограничивать выборку (LIMIT)
Если таблица огромная, запрос без LIMIT может перегрузить сервер.
✅ Добавь ограничение:
SELECT * FROM logs ORDER BY created_at DESC LIMIT 100;
Теперь ты загружаешь только 100 последних записей.
🔥 Вывод:
✔️ Проверяй NULL правильно.
✔️ Используй индексы для ускорения.
✔️ Не выбирай лишние данные.
✔️ Не забывай GROUP BY при агрегатных функциях.
✔️ Добавляй LIMIT, если работаешь с большими таблицами.
❓ А какие ошибки SQL ты встречал в работе? Делись в комментариях!
#SQL #DML #ИТ #Оптимизация_SQL
#Ошибки_SQL
🔥8👍3
🔹 Основы SELECT в SQL – с чего начать?
Оператор SELECT – это сердце SQL. Он позволяет получать данные из таблиц, и сегодня разберём его основные возможности!
📌 Простой запрос – получить все данные из таблицы:
🔹 * выбирает все колонки, но лучше указывать конкретные:
📌 Фильтрация данных – WHERE
Выберем всех пользователей из определённого города:
📌 Сортировка результатов – ORDER BY
Сортируем пользователей по имени (в алфавитном порядке):
🔹 ASC – по возрастанию, DESC – по убыванию.
📌 Ограничение выборки – LIMIT
Выберем только 5 первых записей:
📌 Поиск уникальных значений – DISTINCT
Список всех уникальных городов, где есть пользователи:
📌 Поиск по шаблону – LIKE
Найдём всех, чьё имя начинается с «А»:
🔹 % – любое количество символов, _ – один символ.
📌 Агрегатные функции – COUNT, AVG, SUM
Сколько у нас пользователей?
COUNT подсчитает их количество.
🔥 Вывод:
✔️ SELECT – основной инструмент для работы с данными.
✔️ Фильтруй (WHERE), сортируй (ORDER BY), ограничивай (LIMIT).
✔️ Используй DISTINCT и LIKE для поиска нужных данных.
❓ Какой SELECT ты чаще всего используешь в работе? Делись в комментариях!
#Операторы_и_работа_с_данными #SELECT #SQL #Основы_SQL #DML
#ИТ
Оператор SELECT – это сердце SQL. Он позволяет получать данные из таблиц, и сегодня разберём его основные возможности!
📌 Простой запрос – получить все данные из таблицы:
SELECT * FROM users;
🔹 * выбирает все колонки, но лучше указывать конкретные:
SELECT id, name, email FROM users;
📌 Фильтрация данных – WHERE
Выберем всех пользователей из определённого города:
SELECT name, email FROM users WHERE city = 'Москва';
📌 Сортировка результатов – ORDER BY
Сортируем пользователей по имени (в алфавитном порядке):
SELECT name, email FROM users ORDER BY name ASC;
🔹 ASC – по возрастанию, DESC – по убыванию.
📌 Ограничение выборки – LIMIT
Выберем только 5 первых записей:
SELECT name FROM users LIMIT 5;
📌 Поиск уникальных значений – DISTINCT
Список всех уникальных городов, где есть пользователи:
SELECT DISTINCT city FROM users;
📌 Поиск по шаблону – LIKE
Найдём всех, чьё имя начинается с «А»:
SELECT * FROM users WHERE name LIKE 'А%';
🔹 % – любое количество символов, _ – один символ.
📌 Агрегатные функции – COUNT, AVG, SUM
Сколько у нас пользователей?
SELECT COUNT(*) FROM users;
COUNT подсчитает их количество.
🔥 Вывод:
✔️ SELECT – основной инструмент для работы с данными.
✔️ Фильтруй (WHERE), сортируй (ORDER BY), ограничивай (LIMIT).
✔️ Используй DISTINCT и LIKE для поиска нужных данных.
❓ Какой SELECT ты чаще всего используешь в работе? Делись в комментариях!
#Операторы_и_работа_с_данными #SELECT #SQL #Основы_SQL #DML
#ИТ
🔥6💯4👍3
🔹 Что такое первичный ключ (PRIMARY KEY) в SQL?
Первичный ключ (Primary Key, PK) — это уникальный идентификатор строки в таблице. Он гарантирует, что каждая запись уникальна и может быть найдена без дублирования.
📌 1. Основные свойства первичного ключа:
✅ Уникальность – каждое значение PK не повторяется.
✅ Не NULL – ключ не может быть пустым.
✅ Только один на таблицу – у таблицы может быть только один PK, но он может включать несколько колонок (составной ключ).
🔹 2. Создание первичного ключа
📌 Простой PK (на одной колонке)
🔹 id – это уникальный идентификатор каждого пользователя.
📌 Составной PK (на нескольких колонках)
Если уникальность зависит от двух и более колонок, можно задать составной ключ:
🔹 Теперь пара (user_id, product_id) должна быть уникальной.
🔹 3. Автоматическое создание уникальных PK
Обычно id делают автоинкрементным (AUTO_INCREMENT), чтобы SQL сам назначал уникальные значения:
🔹 Теперь при добавлении нового клиента id увеличивается автоматически:
🔹 4. Почему важно использовать PK?
✔️ Упрощает поиск данных – можно быстро найти запись по id.
✔️ Гарантирует уникальность – исключает дублирование данных.
✔️ Позволяет связывать таблицы – PK используется как внешний ключ (FK) в других таблицах.
📌 Пример связи users и orders через PK и FK:
🔹 Теперь каждый заказ связан с конкретным пользователем.
🔥 Вывод:
✔️ PRIMARY KEY делает данные уникальными и поиск быстрым.
✔️ Автоинкремент (AUTO_INCREMENT) избавляет от ручного задания id.
✔️ PK используется для связи таблиц через FOREIGN KEY.
❓ Используешь ли ты ключи в своих проектах? Делись опытом в комментариях!
#Ключи_и_связи_между_таблицами
#SQL #PRIMARY_KEY #ИТ
@relational_databases
Первичный ключ (Primary Key, PK) — это уникальный идентификатор строки в таблице. Он гарантирует, что каждая запись уникальна и может быть найдена без дублирования.
📌 1. Основные свойства первичного ключа:
✅ Уникальность – каждое значение PK не повторяется.
✅ Не NULL – ключ не может быть пустым.
✅ Только один на таблицу – у таблицы может быть только один PK, но он может включать несколько колонок (составной ключ).
🔹 2. Создание первичного ключа
📌 Простой PK (на одной колонке)
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(100)
);
🔹 id – это уникальный идентификатор каждого пользователя.
📌 Составной PK (на нескольких колонках)
Если уникальность зависит от двух и более колонок, можно задать составной ключ:
CREATE TABLE orders (
user_id INT,
product_id INT,
quantity INT,
PRIMARY KEY (user_id, product_id)
);
🔹 Теперь пара (user_id, product_id) должна быть уникальной.
🔹 3. Автоматическое создание уникальных PK
Обычно id делают автоинкрементным (AUTO_INCREMENT), чтобы SQL сам назначал уникальные значения:
CREATE TABLE customers (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100)
);
🔹 Теперь при добавлении нового клиента id увеличивается автоматически:
INSERT INTO customers (name) VALUES ('Анна');
INSERT INTO customers (name) VALUES ('Иван');__________
id name
1 Анна
2 Иван🔹 4. Почему важно использовать PK?
✔️ Упрощает поиск данных – можно быстро найти запись по id.
✔️ Гарантирует уникальность – исключает дублирование данных.
✔️ Позволяет связывать таблицы – PK используется как внешний ключ (FK) в других таблицах.
📌 Пример связи users и orders через PK и FK:
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100)
);
CREATE TABLE orders (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
amount DECIMAL(10,2),
FOREIGN KEY (user_id) REFERENCES users(id)
);
🔹 Теперь каждый заказ связан с конкретным пользователем.
🔥 Вывод:
✔️ PRIMARY KEY делает данные уникальными и поиск быстрым.
✔️ Автоинкремент (AUTO_INCREMENT) избавляет от ручного задания id.
✔️ PK используется для связи таблиц через FOREIGN KEY.
❓ Используешь ли ты ключи в своих проектах? Делись опытом в комментариях!
#Ключи_и_связи_между_таблицами
#SQL #PRIMARY_KEY #ИТ
@relational_databases
👍6🔥5
🔹 Внешний ключ (FOREIGN KEY)
Внешний ключ (FOREIGN KEY) — Если первичный ключ (PK) гарантирует уникальность записей, то внешний ключ (FK) связывает таблицы между собой. Он указывает на PK другой таблицы, обеспечивая целостность данных.
📌Зачем нужен внешний ключ?
🔹 Создаёт связи между таблицами (например, заказы одной таблицы привязываются к пользователям другой).
🔹 Предотвращает "потерянные" данные – например, нельзя добавить заказ в таблицу orders без существующего пользователя-добавителя в таблице users.
🔹 Обеспечивает каскадное обновление и удаление данных в связанных таблицах.
🔹 Гарантирует уникальность – исключает дублирование данных.
📌Рассмотрим ситуацию: нам нужно создать таблицу users (пользователи) и orders (заказы). При этом делать заказы (в таблице orders) могут только пользователи учтенные в таблице (users). Для этого нужно связать таблицы внешним ключом.
Решим кейс:
1️⃣ Создаём таблицы
📌 Таблица пользователей (users)
📌 Таблица заказов (orders) - связанная с таблицей пользователей (users) через PRIMARY KEY
✅ Теперь нельзя создать заказ, если user_id (из таблицы заказы) не существует в users (из таблицы пользователи):
✔️ Таблица users содержит пользователей.
✔️ Таблица orders хранит заказы и имеет внешний ключ (столбец users_id) ссылаясь на таблицу users (столбец id), в которой он является первичным ключем.
2️⃣ Проверяем связь
Если попробуем добавить заказ с user_id, которого нет:
🔴 Ошибка! Пользователь id = 100 отсутствует.
3️⃣ Что будет при удалении пользователя?
При использовании команды DELETE (удаление записи только в одной из таблиц связанных внешним ключом):
🔴 Ошибка! У пользователя могут быть заказы в таблице orders.
❌ Если в таблице есть внешний ключ, просто так удалить данные не получится, если это нарушит связь.
При работе с командой удаления внешнего ключа, можно использовать следующие варианты:
✔️ CASCADE – Если внешний ключ создан с ON DELETE CASCADE, то при удалении записи в родительской таблице автоматически удалятся все связанные записи в дочерней. После добавления каскадного удаления удалять данные без ошибки можно командой DELETE.
✔️ SET NULL – Если внешний ключ создан с ON DELETE SET NULL, то при удалении родительской записи, внешние ключи в дочерней таблице просто станут NULL
✔️ RESTRICT – запретить удаление, если есть заказы (по умолчанию). Удаление (DELETE) будет доступно только вручную: сначала дочерние записи, потом родительские.
🔥 Итог
✔️ FOREIGN KEY защищает от "битых" данных.
✔️ Связывает таблицы и сохраняет логику.
✔️ Позволяет управлять удалением и обновлением.
💡 Теперь ты знаешь, как связывать таблицы! Используешь FOREIGN KEY в своих проектах?
#Ключи_и_связи_между_таблицами
#SQL #FOREIGN_KEY #ИТ
@relational_databases
Внешний ключ (FOREIGN KEY) — Если первичный ключ (PK) гарантирует уникальность записей, то внешний ключ (FK) связывает таблицы между собой. Он указывает на PK другой таблицы, обеспечивая целостность данных.
📌Зачем нужен внешний ключ?
🔹 Создаёт связи между таблицами (например, заказы одной таблицы привязываются к пользователям другой).
🔹 Предотвращает "потерянные" данные – например, нельзя добавить заказ в таблицу orders без существующего пользователя-добавителя в таблице users.
🔹 Обеспечивает каскадное обновление и удаление данных в связанных таблицах.
🔹 Гарантирует уникальность – исключает дублирование данных.
📌Рассмотрим ситуацию: нам нужно создать таблицу users (пользователи) и orders (заказы). При этом делать заказы (в таблице orders) могут только пользователи учтенные в таблице (users). Для этого нужно связать таблицы внешним ключом.
Решим кейс:
1️⃣ Создаём таблицы
📌 Таблица пользователей (users)
CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT, -- Уникальный идентификатор
name VARCHAR(100) NOT NULL -- Имя пользователя
);
📌 Таблица заказов (orders) - связанная с таблицей пользователей (users) через PRIMARY KEY
CREATE TABLE orders (
id INT PRIMARY KEY AUTO_INCREMENT, -- Уникальный идентификатор заказа
user_id INT, -- ID пользователя, сделавшего заказ
FOREIGN KEY (user_id) REFERENCES users(id) -- Связь с таблицей users
);
✅ Теперь нельзя создать заказ, если user_id (из таблицы заказы) не существует в users (из таблицы пользователи):
✔️ Таблица users содержит пользователей.
✔️ Таблица orders хранит заказы и имеет внешний ключ (столбец users_id) ссылаясь на таблицу users (столбец id), в которой он является первичным ключем.
2️⃣ Проверяем связь
Если попробуем добавить заказ с user_id, которого нет:
INSERT INTO orders (user_id, amount) VALUES (100, 500.00);
🔴 Ошибка! Пользователь id = 100 отсутствует.
3️⃣ Что будет при удалении пользователя?
При использовании команды DELETE (удаление записи только в одной из таблиц связанных внешним ключом):
DELETE FROM users WHERE id = 1;
🔴 Ошибка! У пользователя могут быть заказы в таблице orders.
❌ Если в таблице есть внешний ключ, просто так удалить данные не получится, если это нарушит связь.
При работе с командой удаления внешнего ключа, можно использовать следующие варианты:
✔️ CASCADE – Если внешний ключ создан с ON DELETE CASCADE, то при удалении записи в родительской таблице автоматически удалятся все связанные записи в дочерней. После добавления каскадного удаления удалять данные без ошибки можно командой DELETE.
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
✔️ SET NULL – Если внешний ключ создан с ON DELETE SET NULL, то при удалении родительской записи, внешние ключи в дочерней таблице просто станут NULL
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE SET NULL
✔️ RESTRICT – запретить удаление, если есть заказы (по умолчанию). Удаление (DELETE) будет доступно только вручную: сначала дочерние записи, потом родительские.
🔥 Итог
✔️ FOREIGN KEY защищает от "битых" данных.
✔️ Связывает таблицы и сохраняет логику.
✔️ Позволяет управлять удалением и обновлением.
💡 Теперь ты знаешь, как связывать таблицы! Используешь FOREIGN KEY в своих проектах?
#Ключи_и_связи_между_таблицами
#SQL #FOREIGN_KEY #ИТ
@relational_databases
👍6🔥5🤯4
🔥 HAVING vs WHERE – в чём разница?
Если ты фильтруешь данные в SQL, то наверняка сталкивался с WHERE и HAVING. Оба используются для условий, но работают по-разному. Разберёмся!
1️⃣ WHERE – фильтрует строки до группировки.
Используется для фильтрации отдельных строк перед выполнением GROUP BY.
✅ Пример:
🔹 Оставляет только заказы, где сумма больше 100.
⚠️ WHERE нельзя использовать с агрегатными функциями (COUNT, SUM и т. д.)!
2️⃣ HAVING – фильтрует группы после GROUP BY.
Когда мы уже сгруппировали данные, HAVING позволяет фильтровать агрегированные значения.
✅ Пример:
🔹 Выбираем только пользователей, у которых больше 3 заказов.
⚠️ HAVING работает только после GROUP BY.
3️⃣ Когда использовать WHERE, а когда HAVING?
✔️ WHERE – если фильтруем конкретные строки.
✔️ HAVING – если фильтруем уже сгруппированные данные.
✅ Комбинируем оба:
🔹 Считаем только заказы больше 100 и оставляем пользователей с более чем 3 заказами.
🔥 Итог
✔️ WHERE – фильтрует строки до GROUP BY.
✔️ HAVING – фильтрует после группировки.
✔️ Вместе дают гибкость и мощь в SQL-запросах.
💡 Запомнил разницу? Пиши примеры из своей практики!
#Операторы_и_работа_с_данными
#SQL #HAVING #WHERE #DML #ИТ
@relational_databases
Если ты фильтруешь данные в SQL, то наверняка сталкивался с WHERE и HAVING. Оба используются для условий, но работают по-разному. Разберёмся!
1️⃣ WHERE – фильтрует строки до группировки.
Используется для фильтрации отдельных строк перед выполнением GROUP BY.
✅ Пример:
SELECT * FROM orders WHERE amount > 100;
🔹 Оставляет только заказы, где сумма больше 100.
⚠️ WHERE нельзя использовать с агрегатными функциями (COUNT, SUM и т. д.)!
2️⃣ HAVING – фильтрует группы после GROUP BY.
Когда мы уже сгруппировали данные, HAVING позволяет фильтровать агрегированные значения.
✅ Пример:
SELECT user_id, COUNT(*) AS order_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 3;
🔹 Выбираем только пользователей, у которых больше 3 заказов.
⚠️ HAVING работает только после GROUP BY.
3️⃣ Когда использовать WHERE, а когда HAVING?
✔️ WHERE – если фильтруем конкретные строки.
✔️ HAVING – если фильтруем уже сгруппированные данные.
✅ Комбинируем оба:
SELECT user_id, COUNT(*) AS order_count
FROM orders
WHERE amount > 100 -- Фильтруем заказы до группировки
GROUP BY user_id
HAVING COUNT(*) > 3; -- Фильтруем группы
🔹 Считаем только заказы больше 100 и оставляем пользователей с более чем 3 заказами.
🔥 Итог
✔️ WHERE – фильтрует строки до GROUP BY.
✔️ HAVING – фильтрует после группировки.
✔️ Вместе дают гибкость и мощь в SQL-запросах.
💡 Запомнил разницу? Пиши примеры из своей практики!
#Операторы_и_работа_с_данными
#SQL #HAVING #WHERE #DML #ИТ
@relational_databases
👍11🔥5
🔥 Индексы в SQL: ускоряем запросы к БД
Индексы – это ускорители поиска в базе данных. Без них SQL перебирает все строки в таблице (полный скан), а с индексами – находит нужные данные мгновенно.
Представь, что ищешь главу в книге:
Без индекса → листаешь все страницы.
С индексом → открываешь оглавление и сразу находишь нужную страницу.
Разберёмся, как они работают, когда полезны и как их использовать.
1️⃣ Как создать индекс?
Создаём индекс на колонке, по которой чаще всего выполняются поиск (WHERE), сортировка (ORDER BY) и группировка (GROUP BY):
🔹 Теперь поиск по email станет быстрее, так как база данных не будет просматривать все строки.
2️⃣ Когда индексы полезны?
✔️ В WHERE – ускоряют выборку данных
✔️ В JOIN – индекс на связующих колонках ускоряет объединение
✔️ В ORDER BY и GROUP BY – сортировка и группировка выполняются быстрее
3️⃣ Когда индексы вредны?
❌ Частые изменения данных (INSERT, UPDATE, DELETE) → индексы замедляют операции, так как нужно обновлять структуру.
❌ Слишком много индексов → база начинает занимать много памяти.
❌ Неправильный выбор колонок → индекс не помогает, если он не используется в запросах.
4️⃣ Как удалить индекс?
🔹 Используй, если индекс стал ненужным.
📌 Как проверить, используется ли индекс?
🔹 Если в выводе с EXPLAIN есть Using index, значит, запрос использует индекс!
🔥 Итог
✔️ Индексы ускоряют поиск и сортировку.
✔️ Они замедляют изменения данных.
✔️ Используй EXPLAIN для анализа работы индексов.
✔️ Правильное применение индексов повышает производительность работы с БД.
💡 Хочешь подробнее про индексы? Пиши в комментариях!
#Операторы_и_работа_с_данными
#SQL #Базы_данных #INDEX #Оптимизация #ИТ
@relational_databases
Индексы – это ускорители поиска в базе данных. Без них SQL перебирает все строки в таблице (полный скан), а с индексами – находит нужные данные мгновенно.
Представь, что ищешь главу в книге:
Без индекса → листаешь все страницы.
С индексом → открываешь оглавление и сразу находишь нужную страницу.
Разберёмся, как они работают, когда полезны и как их использовать.
1️⃣ Как создать индекс?
Создаём индекс на колонке, по которой чаще всего выполняются поиск (WHERE), сортировка (ORDER BY) и группировка (GROUP BY):
CREATE INDEX idx_users_email ON users(email);
🔹 Теперь поиск по email станет быстрее, так как база данных не будет просматривать все строки.
2️⃣ Когда индексы полезны?
✔️ В WHERE – ускоряют выборку данных
✔️ В JOIN – индекс на связующих колонках ускоряет объединение
✔️ В ORDER BY и GROUP BY – сортировка и группировка выполняются быстрее
3️⃣ Когда индексы вредны?
❌ Частые изменения данных (INSERT, UPDATE, DELETE) → индексы замедляют операции, так как нужно обновлять структуру.
❌ Слишком много индексов → база начинает занимать много памяти.
❌ Неправильный выбор колонок → индекс не помогает, если он не используется в запросах.
4️⃣ Как удалить индекс?
DROP INDEX idx_users_email ON users;
🔹 Используй, если индекс стал ненужным.
📌 Как проверить, используется ли индекс?
EXPLAIN SELECT * FROM users WHERE email = 'user@example';
🔹 Если в выводе с EXPLAIN есть Using index, значит, запрос использует индекс!
🔥 Итог
✔️ Индексы ускоряют поиск и сортировку.
✔️ Они замедляют изменения данных.
✔️ Используй EXPLAIN для анализа работы индексов.
✔️ Правильное применение индексов повышает производительность работы с БД.
💡 Хочешь подробнее про индексы? Пиши в комментариях!
#Операторы_и_работа_с_данными
#SQL #Базы_данных #INDEX #Оптимизация #ИТ
@relational_databases
🔥11👍4🌚2
🔥 SQL-подзапросы: мощный инструмент в одном запросе!
Подзапрос (subquery) — это запрос внутри запроса, который позволяет получать данные более гибко. Используется там, где обычные JOIN не подходят.
1️⃣ Как работает подзапрос?
Пример: найдём пользователей, у которых есть заказы.
🔹 Внутренний запрос (SELECT user_id FROM orders) получает ID пользователей с заказами.
🔹 Внешний запрос выбирает только этих пользователей.
2️⃣ Основные виды подзапросов
✅ Возвращающий одно значение (используется в WHERE)
🔹 Выбираем товары, которые дороже среднего.
✅ Возвращающий список значений (используется с IN)
🔹 Выбираем клиентов, у которых есть заказы.
✅ Как часть FROM (Derived Table)
🔹 Фильтруем дорогие товары перед группировкой.
3️⃣ Проверка существования данных (EXISTS)
Когда нужно проверить, есть ли связанные записи.
Пример: Найти клиентов, у которых есть хотя бы один заказ.
Когда использовать?
✔️ Если важен только факт наличия записей, EXISTS работает быстрее, чем IN.
4️⃣ Когда подзапросы полезны?
✔️ Когда нельзя использовать JOIN.
✔️ Когда нужны промежуточные вычисления.
✔️ Когда нужно выбрать агрегированные данные (AVG, MAX, COUNT).
⚠️ Но вложенные запросы работают медленнее JOIN!
🔥 Итог
✔️ Подзапросы позволяют делать сложные выборки в одном запросе.
✔️ Но если можно заменить JOIN – лучше использовать его.
✔️ Используй подзапросы для фильтрации и агрегатов.
💡 Хочешь больше примеров? Пиши в комментариях!
#Операторы_и_работа_с_данными
#SQL #Подзапросы #Оптимизация #ИТ #SUBQUERY
@relational_databases
Подзапрос (subquery) — это запрос внутри запроса, который позволяет получать данные более гибко. Используется там, где обычные JOIN не подходят.
1️⃣ Как работает подзапрос?
Пример: найдём пользователей, у которых есть заказы.
SELECT * FROM users
WHERE id IN (SELECT user_id FROM orders);
🔹 Внутренний запрос (SELECT user_id FROM orders) получает ID пользователей с заказами.
🔹 Внешний запрос выбирает только этих пользователей.
2️⃣ Основные виды подзапросов
✅ Возвращающий одно значение (используется в WHERE)
SELECT * FROM products
WHERE price > (SELECT AVG(price) FROM products);
🔹 Выбираем товары, которые дороже среднего.
✅ Возвращающий список значений (используется с IN)
SELECT name FROM customers
WHERE id IN (SELECT customer_id FROM orders);
🔹 Выбираем клиентов, у которых есть заказы.
✅ Как часть FROM (Derived Table)
SELECT category, AVG(price)
FROM (SELECT * FROM products WHERE price > 100) AS expensive_products
GROUP BY category;
🔹 Фильтруем дорогие товары перед группировкой.
3️⃣ Проверка существования данных (EXISTS)
Когда нужно проверить, есть ли связанные записи.
SELECT name FROM customers c
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);
Пример: Найти клиентов, у которых есть хотя бы один заказ.
Когда использовать?
✔️ Если важен только факт наличия записей, EXISTS работает быстрее, чем IN.
4️⃣ Когда подзапросы полезны?
✔️ Когда нельзя использовать JOIN.
✔️ Когда нужны промежуточные вычисления.
✔️ Когда нужно выбрать агрегированные данные (AVG, MAX, COUNT).
⚠️ Но вложенные запросы работают медленнее JOIN!
🔥 Итог
✔️ Подзапросы позволяют делать сложные выборки в одном запросе.
✔️ Но если можно заменить JOIN – лучше использовать его.
✔️ Используй подзапросы для фильтрации и агрегатов.
💡 Хочешь больше примеров? Пиши в комментариях!
#Операторы_и_работа_с_данными
#SQL #Подзапросы #Оптимизация #ИТ #SUBQUERY
@relational_databases
🔥9💯5👍3🌚1
💾 Освойте DDL в SQL и станьте мастером управления структурами БД!
🔥Хотите уверенно проектировать и администрировать реляционные базы данных?
Курс Stepik от автора данного канала Владимира Лунева "DDL в SQL: Определение и управление структурами баз данных" поможет вам разобраться во всех аспектах создания, изменения и удаления объектов БД!
Подписчикам канала скидка на курс 50% по промокоду - RELATIONAL
📚 Что вас ждет?
✅ Сертификат Stepik после окончания курса.
✅ 8 модулей с теорией и практическими заданиями
✅ Глубокое понимание практической работы с реляционными базами данных
✅ Работа с таблицами, ключами, ограничениями, схемами и представлениями, триггерами и правами доступа
✅ Освоение команд CREATE, ALTER, DROP и других возможностей DDL
💡 Этот курс – ваш путь к профессиональному росту в SQL! Независимо от уровня подготовки, вы получите структурированные знания и практику.
https://stepik.org/232192
Присоединяйтесь и прокачайте свои навыки!
#SQL #DDL #БазыДанных #Программирование #IT
🔥Хотите уверенно проектировать и администрировать реляционные базы данных?
Курс Stepik от автора данного канала Владимира Лунева "DDL в SQL: Определение и управление структурами баз данных" поможет вам разобраться во всех аспектах создания, изменения и удаления объектов БД!
Подписчикам канала скидка на курс 50% по промокоду - RELATIONAL
📚 Что вас ждет?
✅ Сертификат Stepik после окончания курса.
✅ 8 модулей с теорией и практическими заданиями
✅ Глубокое понимание практической работы с реляционными базами данных
✅ Работа с таблицами, ключами, ограничениями, схемами и представлениями, триггерами и правами доступа
✅ Освоение команд CREATE, ALTER, DROP и других возможностей DDL
💡 Этот курс – ваш путь к профессиональному росту в SQL! Независимо от уровня подготовки, вы получите структурированные знания и практику.
https://stepik.org/232192
Присоединяйтесь и прокачайте свои навыки!
#SQL #DDL #БазыДанных #Программирование #IT
🔥8👍2🌚2💯2
🔥 JOIN vs. SUBQUERY: что лучше?
В SQL часто приходится выбирать между JOIN и подзапросом (SUBQUERY). Какой вариант использовать? Давай разберёмся!
1️⃣ JOIN: соединение таблиц.
Используется, когда нужно получить данные из нескольких таблиц одновременно.
Пример: Получим список заказов и имена клиентов.
📌 Когда использовать?
✔️ Если нужно вернуть сразу несколько колонок из разных таблиц.
✔️ Работает быстрее на больших данных.
2️⃣ Подзапрос (SUBQUERY): вложенный запрос.
Используется, когда нужно сначала получить данные, а потом их использовать.
Пример: Найдём клиентов, у которых есть заказы.
📌 Когда использовать?
✔️ Если подзапрос возвращает одно значение (AVG, MAX).
✔️ Если нужно упростить код, избегая сложных JOIN.
Вывод: JOIN лучше для больших данных и сложных связей, SUBQUERY – когда нужен простой и понятный код.
💡 А ты что чаще используешь? Пиши в комментариях!
#Операторы_и_работа_с_данными
#SQL #JOIN #Подзапросы #Оптимизация #SUBQUERY
@relational_databases
В SQL часто приходится выбирать между JOIN и подзапросом (SUBQUERY). Какой вариант использовать? Давай разберёмся!
1️⃣ JOIN: соединение таблиц.
Используется, когда нужно получить данные из нескольких таблиц одновременно.
Пример: Получим список заказов и имена клиентов.
SELECT orders.id, customers.name, orders.amount
FROM orders
JOIN customers ON orders.customer_id = customers.id;
📌 Когда использовать?
✔️ Если нужно вернуть сразу несколько колонок из разных таблиц.
✔️ Работает быстрее на больших данных.
2️⃣ Подзапрос (SUBQUERY): вложенный запрос.
Используется, когда нужно сначала получить данные, а потом их использовать.
Пример: Найдём клиентов, у которых есть заказы.
SELECT name FROM customers
WHERE id IN (SELECT customer_id FROM orders);
📌 Когда использовать?
✔️ Если подзапрос возвращает одно значение (AVG, MAX).
✔️ Если нужно упростить код, избегая сложных JOIN.
Вывод: JOIN лучше для больших данных и сложных связей, SUBQUERY – когда нужен простой и понятный код.
💡 А ты что чаще используешь? Пиши в комментариях!
#Операторы_и_работа_с_данными
#SQL #JOIN #Подзапросы #Оптимизация #SUBQUERY
@relational_databases
👍6🔥4💯2
🔥 Как SQL-запросы превращаются в результат?
Разбираем шаги выполнения.
Ты пишешь SQL-запрос, нажимаешь Execute… и через мгновение получаешь данные. Но что происходит "под капотом"?
1️⃣ Парсинг (Parsing) 🧐
СУБД проверяет запрос:
✔️ Есть ли синтаксические ошибки?
✔️ Существуют ли таблицы и колонки?
Пример ошибки:
📌 Если есть ошибка – выполнение прекращается.
2️⃣ Оптимизация (Optimization) 🚀
Если синтаксис верный, база ищет лучший способ выполнения.
✔️ Какой индекс использовать?
✔️ В каком порядке соединять таблицы (JOIN)?
✔️ Можно ли пропустить ненужные строки?
🔍 SQL-подсказка:
📌 Помогает понять, как именно будет выполняться запрос используй команду - EXPLAIN
3️⃣ План выполнения (Execution Plan) 🛠
База строит оптимальный алгоритм:
✔️ Читает индексы, если они есть.
✔️ Соединяет таблицы (JOIN).
✔️ Группирует и фильтрует данные (WHERE, GROUP BY).
4️⃣ Исполнение (Execution) ⚡️
Теперь СУБД запускает код и выбирает данные.
✔️ Читает с диска или из кеша.
✔️ Применяет фильтры и сортировку.
✔️ Возвращает результат.
📌 На этом этапе важна скорость диска, объём оперативной памяти и индексы!
5️⃣ Возвращение результата (Result) 📤
База отправляет данные клиенту. Чем больше строк – тем дольше передача.
✔️ Для ускорения – выбирай только нужные колонки:
✔️ Используй пагинацию (LIMIT), если данных много:
🎯 Итог
Когда ты пишешь SQL-запрос, он проходит 5 этапов:
✅ Парсинг – проверка синтаксиса.
✅ Оптимизация – поиск лучшего способа выполнения.
✅ План выполнения – выбор индексов и алгоритмов.
✅ Исполнение – чтение данных и фильтрация.
✅ Возвращение – отправка результата клиенту.
#SQL #Реляционные_базы_данных #Основы_SQL #ИТ
Разбираем шаги выполнения.
Ты пишешь SQL-запрос, нажимаешь Execute… и через мгновение получаешь данные. Но что происходит "под капотом"?
1️⃣ Парсинг (Parsing) 🧐
СУБД проверяет запрос:
✔️ Есть ли синтаксические ошибки?
✔️ Существуют ли таблицы и колонки?
Пример ошибки:
SELECT name FORM users; -- Опечатка в FROM!
📌 Если есть ошибка – выполнение прекращается.
2️⃣ Оптимизация (Optimization) 🚀
Если синтаксис верный, база ищет лучший способ выполнения.
✔️ Какой индекс использовать?
✔️ В каком порядке соединять таблицы (JOIN)?
✔️ Можно ли пропустить ненужные строки?
🔍 SQL-подсказка:
EXPLAIN SELECT * FROM orders WHERE amount > 1000;
📌 Помогает понять, как именно будет выполняться запрос используй команду - EXPLAIN
3️⃣ План выполнения (Execution Plan) 🛠
База строит оптимальный алгоритм:
✔️ Читает индексы, если они есть.
✔️ Соединяет таблицы (JOIN).
✔️ Группирует и фильтрует данные (WHERE, GROUP BY).
4️⃣ Исполнение (Execution) ⚡️
Теперь СУБД запускает код и выбирает данные.
✔️ Читает с диска или из кеша.
✔️ Применяет фильтры и сортировку.
✔️ Возвращает результат.
📌 На этом этапе важна скорость диска, объём оперативной памяти и индексы!
5️⃣ Возвращение результата (Result) 📤
База отправляет данные клиенту. Чем больше строк – тем дольше передача.
✔️ Для ускорения – выбирай только нужные колонки:
SELECT id, name FROM users; -- Вместо SELECT *
✔️ Используй пагинацию (LIMIT), если данных много:
SELECT * FROM orders LIMIT 50 OFFSET 100;
🎯 Итог
Когда ты пишешь SQL-запрос, он проходит 5 этапов:
✅ Парсинг – проверка синтаксиса.
✅ Оптимизация – поиск лучшего способа выполнения.
✅ План выполнения – выбор индексов и алгоритмов.
✅ Исполнение – чтение данных и фильтрация.
✅ Возвращение – отправка результата клиенту.
#SQL #Реляционные_базы_данных #Основы_SQL #ИТ
🔥9💯4👍3
🔥 Гайд - SELECT на практике: разбор с примерами 📊
Оператор SELECT – это основа работы с данными в SQL. Он позволяет извлекать информацию из таблиц, фильтровать, сортировать и анализировать её. Разберём его работу на реальном примере.
🗄 Исходная таблица employees (Сотрудники)
Представим, что у нас есть база данных компании, содержащая информацию о её сотрудниках.
* Названия городов в city сократил, т.к не влезает в таблицу для телеги, дальше они будут написаны полностью, department также сокращен.
🔹 1. Выбор всех данных (SELECT *)
Если нам нужно получить все данные из таблицы employees, используем SELECT *:
✔️ Этот запрос выведет все строки и все колонки таблицы.
❗️ Использование SELECT * в больших таблицах может замедлить работу БД – лучше выбирать только нужные колонки.
🔹 2. Выбор конкретных колонок
Чтобы извлечь только имена, отдел и зарплаты сотрудников:
✔️ Указывая нужные колонки, мы уменьшаем нагрузку на сервер и упрощаем анализ данных.
Результат:
🔹 3. Фильтрация данных (WHERE)
Выбираем сотрудников из IT-отдела:
✔️ WHERE помогает выбирать только нужные данные.
Результат:
🔹 4. Фильтрация по числовым значениям
Выбираем сотрудников с зарплатой выше 100000:
✔️ >, <, >=, <= – используются для сравнения чисел.
Результат:
🔹 5. Условия с AND и OR
Выбираем сотрудников из Москвы и IT-отдела:
✔️ AND – оба условия должны выполняться одновременно.
Результат:
🔹 6. Сортировка данных (ORDER BY)
Сортируем сотрудников по зарплате (по убыванию):
✔️ DESC – сортировка по убыванию, ASC – по возрастанию (по умолчанию).
Результат:
🔹 7. Уникальные значения (DISTINCT)
Хотим узнать, какие уникальные отделы есть в компании:
✔️ DISTINCT убирает повторяющиеся значения.
Результат:
🔹 8. Ограничение числа строк (LIMIT)
Выбираем топ-3 самых высокооплачиваемых сотрудников:
✔️ LIMIT используется, когда нужно вывести только несколько записей.
Результат:
🔹 9. Поиск по шаблону (LIKE)
Хотим найти всех сотрудников, чьи имена начинаются с "И":
✔️ % – заменяет любое количество символов.
✔️ _ – заменяет только один символ.
Результат:
🚀 Итог
✅ SELECT * – получить все данные.
✅ SELECT column1, column2 – выбрать конкретные колонки.
✅ WHERE – фильтрация данных.
✅ AND / OR – сложные условия.
✅ ORDER BY – сортировка данных.
✅ DISTINCT – уникальные значения.
✅ LIMIT – ограничение строк.
✅ LIKE – поиск по шаблону.
📌 Какой SQL-запрос ты используешь чаще всего? Делись в комментариях!
💡Курс от автора канала на Stepik
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #SELECT #DML #Гайд
@relational_databases
Оператор SELECT – это основа работы с данными в SQL. Он позволяет извлекать информацию из таблиц, фильтровать, сортировать и анализировать её. Разберём его работу на реальном примере.
🗄 Исходная таблица employees (Сотрудники)
Представим, что у нас есть база данных компании, содержащая информацию о её сотрудниках.
id name age deprt* salary city*
1 Иван 28 IT 120000 МСК
2 Ольга 34 HR 90000 СПБ
3 Дмитрий 40 IT 150000 МСК
4 Анна 25 Mar 85000 Каз
5 Сергей 30 IT 130000 НСК
6 Наталья 29 HR 95000 МСК
* Названия городов в city сократил, т.к не влезает в таблицу для телеги, дальше они будут написаны полностью, department также сокращен.
🔹 1. Выбор всех данных (SELECT *)
Если нам нужно получить все данные из таблицы employees, используем SELECT *:
SELECT * FROM employees;
✔️ Этот запрос выведет все строки и все колонки таблицы.
❗️ Использование SELECT * в больших таблицах может замедлить работу БД – лучше выбирать только нужные колонки.
🔹 2. Выбор конкретных колонок
Чтобы извлечь только имена, отдел и зарплаты сотрудников:
SELECT name, department, salary FROM employees;
✔️ Указывая нужные колонки, мы уменьшаем нагрузку на сервер и упрощаем анализ данных.
Результат:
name department salary
Иван IT 120000
Ольга HR 90000
Дмитрий IT 150000
Анна Marketing 85000
Сергей IT 130000
Наталья HR 95000
🔹 3. Фильтрация данных (WHERE)
Выбираем сотрудников из IT-отдела:
SELECT name, salary FROM employees WHERE department = 'IT';
✔️ WHERE помогает выбирать только нужные данные.
Результат:
name salary
Иван 120000
Дмитрий 150000
Сергей 130000
🔹 4. Фильтрация по числовым значениям
Выбираем сотрудников с зарплатой выше 100000:
SELECT name, salary FROM employees WHERE salary > 100000;
✔️ >, <, >=, <= – используются для сравнения чисел.
Результат:
name salary
Иван 120000
Дмитрий 150000
Сергей 130000
🔹 5. Условия с AND и OR
Выбираем сотрудников из Москвы и IT-отдела:
SELECT name FROM employees WHERE city = 'Москва' AND department = 'IT';
✔️ AND – оба условия должны выполняться одновременно.
Результат:
name
Иван
Дмитрий
🔹 6. Сортировка данных (ORDER BY)
Сортируем сотрудников по зарплате (по убыванию):
SELECT name, salary FROM employees ORDER BY salary DESC;
✔️ DESC – сортировка по убыванию, ASC – по возрастанию (по умолчанию).
Результат:
name salary
Дмитрий 150000
Сергей 130000
Иван 120000
Наталья 95000
Ольга 90000
Анна 85000
🔹 7. Уникальные значения (DISTINCT)
Хотим узнать, какие уникальные отделы есть в компании:
SELECT DISTINCT department FROM employees;
✔️ DISTINCT убирает повторяющиеся значения.
Результат:
department
IT
HR
Marketing
🔹 8. Ограничение числа строк (LIMIT)
Выбираем топ-3 самых высокооплачиваемых сотрудников:
SELECT name, salary FROM employees ORDER BY salary DESC LIMIT 3;
✔️ LIMIT используется, когда нужно вывести только несколько записей.
Результат:
name salary
Дмитрий 150000
Сергей 130000
Иван 120000
🔹 9. Поиск по шаблону (LIKE)
Хотим найти всех сотрудников, чьи имена начинаются с "И":
SELECT name FROM employees WHERE name LIKE 'И%';
✔️ % – заменяет любое количество символов.
✔️ _ – заменяет только один символ.
Результат:
name
Иван
🚀 Итог
✅ SELECT * – получить все данные.
✅ SELECT column1, column2 – выбрать конкретные колонки.
✅ WHERE – фильтрация данных.
✅ AND / OR – сложные условия.
✅ ORDER BY – сортировка данных.
✅ DISTINCT – уникальные значения.
✅ LIMIT – ограничение строк.
✅ LIKE – поиск по шаблону.
📌 Какой SQL-запрос ты используешь чаще всего? Делись в комментариях!
💡Курс от автора канала на Stepik
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #SELECT #DML #Гайд
@relational_databases
🔥12👍3💯3🤯1
📝 INSERT в SQL: добавляем данные правильно!
Оператор INSERT позволяет добавлять новые строки в таблицу. Разберёмся на понятном примере.
🗄 Исходная таблица employees
🔹 Таблица хранит ID сотрудника, имя, должность и зарплату.
1️⃣ Добавление одной строки
✔️Добавит сотрудника Дмитрия с зарплатой 110000.
📌 Важно!
✔️Указываем список колонок и значения в том же порядке.
✔️Если не передавать id, он должен заполняться автоматически (AUTO_INCREMENT).
2️⃣ Добавление нескольких строк сразу
✔️ Позволяет сразу добавить несколько записей, ускоряя процесс.
3️⃣ Добавление данных из другой таблицы
✔️ Копирует данные из таблицы new_hires.
📌 Зачем это нужно?
✔️Можно загружать данные из временных таблиц.
✔️Упрощает миграцию между базами.
4️⃣ Добавление данных без указания колонок
✔️ Работает, но опасно ❗️
❗️Должен быть точный порядок колонок в таблице.
❗️Добавление новых колонок может сломать код.
❗️Лучше всегда указывать список колонок!
5️⃣ INSERT с DEFAULT значениями
✔️ Заполнит salary значением по умолчанию (если оно задано).
🔥 Итоги
✅ INSERT INTO ... VALUES (...) – стандартный способ.
✅ Можно добавлять несколько строк сразу.
✅ INSERT INTO ... SELECT – полезен для копирования данных.
✅ Всегда указывайте список колонок – это безопаснее.
✅ DEFAULT помогает использовать значения по умолчанию.
💬 Какие ошибки ты встречал при INSERT? Делись в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #INSERT #DML
@relational_databases
Оператор INSERT позволяет добавлять новые строки в таблицу. Разберёмся на понятном примере.
🗄 Исходная таблица employees
id name position salary
1 Иван Менеджер 120000
2 Ольга Разработчик 150000
🔹 Таблица хранит ID сотрудника, имя, должность и зарплату.
1️⃣ Добавление одной строки
INSERT INTO employees (id, name, position, salary)
VALUES (3, 'Дмитрий', 'Аналитик', 110000);
✔️Добавит сотрудника Дмитрия с зарплатой 110000.
📌 Важно!
✔️Указываем список колонок и значения в том же порядке.
✔️Если не передавать id, он должен заполняться автоматически (AUTO_INCREMENT).
2️⃣ Добавление нескольких строк сразу
INSERT INTO employees (id, name, position, salary)
VALUES
(4, 'Анна', 'Тестировщик', 95000),
(5, 'Максим', 'Разработчик', 140000);
✔️ Позволяет сразу добавить несколько записей, ускоряя процесс.
3️⃣ Добавление данных из другой таблицы
INSERT INTO employees (id, name, position, salary)
SELECT id, name, position, salary FROM new_hires;
✔️ Копирует данные из таблицы new_hires.
📌 Зачем это нужно?
✔️Можно загружать данные из временных таблиц.
✔️Упрощает миграцию между базами.
4️⃣ Добавление данных без указания колонок
INSERT INTO employees
VALUES (6, 'Елена', 'HR', 100000);
✔️ Работает, но опасно ❗️
❗️Должен быть точный порядок колонок в таблице.
❗️Добавление новых колонок может сломать код.
❗️Лучше всегда указывать список колонок!
5️⃣ INSERT с DEFAULT значениями
INSERT INTO employees (id, name, position, salary)
VALUES (7, 'Сергей', 'DevOps', DEFAULT);
✔️ Заполнит salary значением по умолчанию (если оно задано).
🔥 Итоги
✅ INSERT INTO ... VALUES (...) – стандартный способ.
✅ Можно добавлять несколько строк сразу.
✅ INSERT INTO ... SELECT – полезен для копирования данных.
✅ Всегда указывайте список колонок – это безопаснее.
✅ DEFAULT помогает использовать значения по умолчанию.
💬 Какие ошибки ты встречал при INSERT? Делись в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #INSERT #DML
@relational_databases
🔥11👍4🤔4🌚1
🔄 UPDATE в SQL: как обновлять данные правильно?
UPDATE в SQL позволяет изменять существующие записи в таблице.
Разберёмся, как это делать безопасно и эффективно.
🗄 Исходная таблица employees
🔹 Таблица содержит ID, имя, должность и зарплату сотрудников.
1️⃣ Обновление одной строки
✔️ Увеличит зарплату Ивану до 130000.
❗️Важно! Без WHERE обновятся ВСЕ записи. Всегда проверяйте условие перед выполнением.
2️⃣ Обновление нескольких колонок сразу
✔️Теперь Ольга – Senior Разработчик с зарплатой 170000.
📌 Преимущество: Можно изменять сразу несколько полей, ускоряя процесс.
3️⃣ Массовое обновление нескольких строк
✔️ На 10% увеличит зарплаты всем разработчикам.
📌 Зачем это нужно?
Можно групповыми изменениями повышать зарплаты, корректировать данные.
salary * 1.1 – работает как формула.
4️⃣ Обновление на основе данных из другой таблицы
Допустим, у нас есть таблица salary_changes с новыми зарплатами:
Теперь обновим зарплаты в employees:
✔️ Обновит зарплаты для сотрудников, которые есть в salary_changes.
📌 Используем подзапрос для выборки новых значений. Пост про вложенные запросы тут
5️⃣ Условное обновление с CASE
Вместо нескольких UPDATE используем один запрос с CASE
✔️ Гибко обновит зарплаты в зависимости от должности.
📌 Когда полезно?
Разные правила для разных сотрудников.
Можно обновлять данные без нескольких UPDATE.
🔥 Итоги
✅ UPDATE ... SET ... WHERE – основной способ.
✅ Без WHERE можно случайно обновить ВСЕ данные ❗️
✅ Можно обновлять несколько колонок сразу.
✅ Подзапросы позволяют обновлять данные из других таблиц.
✅ CASE помогает задать разные условия в одном запросе.
💬 Какой UPDATE ты использовал чаще всего? Делись в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #UPDATE #DML
@relational_databases
UPDATE в SQL позволяет изменять существующие записи в таблице.
Разберёмся, как это делать безопасно и эффективно.
🗄 Исходная таблица employees
id name position salary
1 Иван Менеджер 120000
2 Ольга Разработчик 150000
3 Дмитрий Аналитик 110000
🔹 Таблица содержит ID, имя, должность и зарплату сотрудников.
1️⃣ Обновление одной строки
UPDATE employees
SET salary = 130000
WHERE id = 1;
✔️ Увеличит зарплату Ивану до 130000.
❗️Важно! Без WHERE обновятся ВСЕ записи. Всегда проверяйте условие перед выполнением.
2️⃣ Обновление нескольких колонок сразу
UPDATE employees
SET position = 'Senior Разработчик', salary = 170000
WHERE name = 'Ольга';
✔️Теперь Ольга – Senior Разработчик с зарплатой 170000.
📌 Преимущество: Можно изменять сразу несколько полей, ускоряя процесс.
3️⃣ Массовое обновление нескольких строк
UPDATE employees
SET salary = salary * 1.1
WHERE position = 'Разработчик';
✔️ На 10% увеличит зарплаты всем разработчикам.
📌 Зачем это нужно?
Можно групповыми изменениями повышать зарплаты, корректировать данные.
salary * 1.1 – работает как формула.
4️⃣ Обновление на основе данных из другой таблицы
Допустим, у нас есть таблица salary_changes с новыми зарплатами:
id new_salary
1 135000
3 120000
Теперь обновим зарплаты в employees:
UPDATE employees e
SET salary = (SELECT new_salary FROM salary_changes sc WHERE e.id = sc.id)
WHERE id IN (SELECT id FROM salary_changes);
✔️ Обновит зарплаты для сотрудников, которые есть в salary_changes.
📌 Используем подзапрос для выборки новых значений. Пост про вложенные запросы тут
5️⃣ Условное обновление с CASE
Вместо нескольких UPDATE используем один запрос с CASE
UPDATE employees
SET salary = CASE
WHEN position = 'Менеджер' THEN salary * 1.2
WHEN position = 'Разработчик' THEN salary * 1.15
ELSE salary * 1.1
END;
✔️ Гибко обновит зарплаты в зависимости от должности.
📌 Когда полезно?
Разные правила для разных сотрудников.
Можно обновлять данные без нескольких UPDATE.
🔥 Итоги
✅ UPDATE ... SET ... WHERE – основной способ.
✅ Без WHERE можно случайно обновить ВСЕ данные ❗️
✅ Можно обновлять несколько колонок сразу.
✅ Подзапросы позволяют обновлять данные из других таблиц.
✅ CASE помогает задать разные условия в одном запросе.
💬 Какой UPDATE ты использовал чаще всего? Делись в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #UPDATE #DML
@relational_databases
🔥7👍4
🗑 Удаление данных в SQL: основы DELETE
Удаление данных — важная часть работы с БД. В SQL для этого используется оператор DELETE, который позволяет удалять конкретные строки в таблице.
Разберем основные типы манипуляций по удалению с исходной таблицей employees (таблица в картинке поста)
1️⃣ Удаление всех строк
✔️ Удаляет все записи из таблицы.
🔹 Важно! Структура таблицы остается, но без данных.
2️⃣ Удаление с условием (WHERE)
✔️ Удаляет только тех сотрудников, у кого position = 'Analyst'.
После выполнения запроса строка 3 исходной таблицы (картинка в посте) исчезнет.
3️⃣ Удаление с подзапросом. Пост про вложенные запросы тут
✔️Удаляет всех, у кого зарплата меньше 55 000.
🔹 IN (SELECT ...) находит id подходящих строк перед удалением.
4️⃣ Удаление без удаления структуры
❌ DELETE не сбрасывает автоинкремент (AUTO_INCREMENT).
✔️ Если после DELETE добавить новую запись, её id не начнётся с 1, а продолжит счёт.
Если нужно сбросить счётчик, используй:
⚠️ Нужно учесть, что это изменит Id и других записей
⚠️ Когда использовать DELETE?
✅ Удаление отдельных строк по условию.
✅ Удаление с учетом зависимостей (FOREIGN KEY). Пост про внешние ключи тут
✅ Удаление с возможностью отката (ROLLBACK).
❌ Не использовать для полной очистки таблицы! Для этого есть TRUNCATE, но он относится к DDL и не поддерживает откат.
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #DELETE #DML
Удаление данных — важная часть работы с БД. В SQL для этого используется оператор DELETE, который позволяет удалять конкретные строки в таблице.
Разберем основные типы манипуляций по удалению с исходной таблицей employees (таблица в картинке поста)
1️⃣ Удаление всех строк
DELETE FROM employees;
✔️ Удаляет все записи из таблицы.
🔹 Важно! Структура таблицы остается, но без данных.
2️⃣ Удаление с условием (WHERE)
DELETE FROM employees WHERE position = 'Analyst';
✔️ Удаляет только тех сотрудников, у кого position = 'Analyst'.
После выполнения запроса строка 3 исходной таблицы (картинка в посте) исчезнет.
3️⃣ Удаление с подзапросом. Пост про вложенные запросы тут
DELETE FROM employees
WHERE id IN (SELECT id FROM employees WHERE salary < 55000);
✔️Удаляет всех, у кого зарплата меньше 55 000.
🔹 IN (SELECT ...) находит id подходящих строк перед удалением.
4️⃣ Удаление без удаления структуры
❌ DELETE не сбрасывает автоинкремент (AUTO_INCREMENT).
✔️ Если после DELETE добавить новую запись, её id не начнётся с 1, а продолжит счёт.
Если нужно сбросить счётчик, используй:
ALTER TABLE employees AUTO_INCREMENT = 1;
⚠️ Нужно учесть, что это изменит Id и других записей
⚠️ Когда использовать DELETE?
✅ Удаление отдельных строк по условию.
✅ Удаление с учетом зависимостей (FOREIGN KEY). Пост про внешние ключи тут
✅ Удаление с возможностью отката (ROLLBACK).
❌ Не использовать для полной очистки таблицы! Для этого есть TRUNCATE, но он относится к DDL и не поддерживает откат.
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #DELETE #DML
👍9🔥3🌚3
🔥10 ОШИБОК В SQL, КОТОРЫЕ ДОРОГО СТОЯТ
При работе с базами данных всегда нужно помнить, что даже одна ошибка может привести к потере данных, неожиданным багам и замедлению работы БД.
Разбираем опасные ошибки и как их избежать!
1️⃣ Удаление без WHERE
❌ Ошибка: Удаляет все строки в таблице, если не указать WHERE.
✔️ Правильный вариант: Добавляем WHERE, чтобы удалить только нужные данные.
✔️ Если хочешь удалить всё, но сохранить структуру, лучше использовать TRUNCATE (но это уже DDL, а не DML).
2️⃣ Обновление без WHERE
❌ Ошибка: Обновляет все строки в таблице, даже если это не требуется.
✔️ Правильный вариант: Используем WHERE, чтобы обновить только нужные записи.
3️⃣ Дублирование данных при INSERT
❌ Ошибка: Если запись с таким id уже есть, получим ошибку.
✔️ Правильный вариант: Если id = 1 уже существует, обновляем запись.
✔️ В PostgreSQL аналог:
4️⃣ Пропуск ROLLBACK в транзакциях
❌ Ошибка: Если не выполнить ROLLBACK, транзакция зависнет, а данные останутся заблокированными.
✔️ Правильный вариант: Закрываем транзакцию COMMIT или ROLLBACK.
5️⃣ Невнимательность к NULL
❌ Ошибка: NULL не участвует в сравнении, поэтому часть данных теряется.
✔️ Правильный вариант: Добавляем OR age IS NULL, если NULL допустим.
6️⃣ Забытые RETURNING в DELETE и UPDATE (PostgreSQL, Oracle)
❌ Ошибка: Мы удалили или обновили данные, но не знаем какие именно.
✔️ Правильный вариант: Используем RETURNING, чтобы получить удалённые записи.
7️⃣ Использование DELETE вместо TRUNCATE для очистки таблицы
❌ Ошибка: DELETE удаляет строки по одной, что медленно на больших объёмах.
✔️ Лучший вариант (но это уже DDL):
✔️ В DML можно использовать DELETE с RETURNING, если важен список удалённых данных.
8️⃣ Неиспользование LIMIT при массовых изменениях
❌ Ошибка: Этот запрос может удалить миллионы строк и создать нагрузку.
✔️ Лучший вариант: Удаляем порциями, если данных много.
📌 Сохрани, чтобы не допустить эти ошибки!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #Оптимизация_SQL #Ошибки_SQL
При работе с базами данных всегда нужно помнить, что даже одна ошибка может привести к потере данных, неожиданным багам и замедлению работы БД.
Разбираем опасные ошибки и как их избежать!
1️⃣ Удаление без WHERE
❌ Ошибка: Удаляет все строки в таблице, если не указать WHERE.
DELETE FROM orders;
✔️ Правильный вариант: Добавляем WHERE, чтобы удалить только нужные данные.
DELETE FROM orders WHERE status = 'canceled';
✔️ Если хочешь удалить всё, но сохранить структуру, лучше использовать TRUNCATE (но это уже DDL, а не DML).
TRUNCATE TABLE orders; -- Очищает таблицу мгновенно
2️⃣ Обновление без WHERE
❌ Ошибка: Обновляет все строки в таблице, даже если это не требуется.
UPDATE employees SET salary = salary * 1.1;
✔️ Правильный вариант: Используем WHERE, чтобы обновить только нужные записи.
UPDATE employees SET salary = salary * 1.1 WHERE department = 'IT';
3️⃣ Дублирование данных при INSERT
❌ Ошибка: Если запись с таким id уже есть, получим ошибку.
INSERT INTO users (id, name) VALUES (1, 'Alice');
✔️ Правильный вариант: Если id = 1 уже существует, обновляем запись.
INSERT INTO users (id, name) VALUES (1, 'Alice')
ON DUPLICATE KEY UPDATE name = 'Alice'; -- MySQL
✔️ В PostgreSQL аналог:
INSERT INTO users (id, name) VALUES (1, 'Alice')
ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name;
4️⃣ Пропуск ROLLBACK в транзакциях
❌ Ошибка: Если не выполнить ROLLBACK, транзакция зависнет, а данные останутся заблокированными.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- Ошибка в коде, транзакция зависла
✔️ Правильный вариант: Закрываем транзакцию COMMIT или ROLLBACK.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT; -- Фиксируем изменения
-- Если что-то пошло не так:
ROLLBACK; -- Отменяем изменения
5️⃣ Невнимательность к NULL
❌ Ошибка: NULL не участвует в сравнении, поэтому часть данных теряется.
SELECT * FROM users WHERE age > 30;
✔️ Правильный вариант: Добавляем OR age IS NULL, если NULL допустим.
SELECT * FROM users WHERE age > 30 OR age IS NULL;
6️⃣ Забытые RETURNING в DELETE и UPDATE (PostgreSQL, Oracle)
❌ Ошибка: Мы удалили или обновили данные, но не знаем какие именно.
DELETE FROM orders WHERE status = 'canceled';
✔️ Правильный вариант: Используем RETURNING, чтобы получить удалённые записи.
DELETE FROM orders WHERE status = 'canceled' RETURNING *;
7️⃣ Использование DELETE вместо TRUNCATE для очистки таблицы
❌ Ошибка: DELETE удаляет строки по одной, что медленно на больших объёмах.
DELETE FROM logs;
✔️ Лучший вариант (но это уже DDL):
TRUNCATE TABLE logs; -- Очищает таблицу быстрее
✔️ В DML можно использовать DELETE с RETURNING, если важен список удалённых данных.
DELETE FROM logs RETURNING COUNT(*);
8️⃣ Неиспользование LIMIT при массовых изменениях
❌ Ошибка: Этот запрос может удалить миллионы строк и создать нагрузку.
DELETE FROM sessions WHERE created_at < NOW() - INTERVAL '30 days';
✔️ Лучший вариант: Удаляем порциями, если данных много.
DELETE FROM sessions WHERE created_at < NOW() - INTERVAL '30 days' LIMIT 1000;
📌 Сохрани, чтобы не допустить эти ошибки!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #Оптимизация_SQL #Ошибки_SQL
👍6🔥4🌚3
🔥 Необычные SQL-команды, о которых знают не все!
SQL — это не только SELECT, INSERT, UPDATE и DELETE. Есть малоизвестные, но полезные команды, которые могут упростить жизнь. Разберём 4 необычные команды с примерами!
1️⃣ COALESCE — замена NULL на значение по умолчанию
Иногда в данных встречается NULL, который ломает вычисления. COALESCE помогает заменить NULL на значение по умолчанию.
✅ Пример:
🔹 Почему? Если salary равно NULL, вместо него подставится 50000.
2️⃣ INSERT IGNORE — вставка без ошибок
Если пытаетесь вставить строку, но она нарушает ограничения (например, уникальный ключ), стандартный INSERT выдаст ошибку. INSERT IGNORE просто пропустит конфликтную запись.
✅ Пример:
🔹 Почему? Если запись с id = 1 уже есть, ошибка не произойдёт.
3️⃣ REGEXP — поиск по шаблону (MySQL, PostgreSQL)
Когда LIKE не справляется, можно использовать REGEXP для гибкого поиска по регулярным выражениям.
✅ Пример:
🔹 Почему? Найдёт всех, чьё имя начинается с «Андрей» или «Алексей».
4️⃣ LATERAL — динамические подзапросы (PostgreSQL, Oracle)
Позволяет передавать данные из одного запроса в другой внутри JOIN.
✅ Пример:
🔹 Почему? Покажет только один последний заказ для каждого пользователя.
📌 Вывод:
⚡️ COALESCE спасает от NULL
⚡️ INSERT IGNORE предотвращает ошибки вставки
⚡️ REGEXP расширяет возможности поиска
⚡️ LATERAL даёт гибкость подзапросам
💡 Знал ли ты о всех этих командах? Делись в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #DML
SQL — это не только SELECT, INSERT, UPDATE и DELETE. Есть малоизвестные, но полезные команды, которые могут упростить жизнь. Разберём 4 необычные команды с примерами!
1️⃣ COALESCE — замена NULL на значение по умолчанию
Иногда в данных встречается NULL, который ломает вычисления. COALESCE помогает заменить NULL на значение по умолчанию.
✅ Пример:
SELECT name, COALESCE(salary, 50000) AS salary
FROM employees;
🔹 Почему? Если salary равно NULL, вместо него подставится 50000.
2️⃣ INSERT IGNORE — вставка без ошибок
Если пытаетесь вставить строку, но она нарушает ограничения (например, уникальный ключ), стандартный INSERT выдаст ошибку. INSERT IGNORE просто пропустит конфликтную запись.
✅ Пример:
INSERT IGNORE INTO users (id, name)
VALUES (1, 'Иван');
🔹 Почему? Если запись с id = 1 уже есть, ошибка не произойдёт.
3️⃣ REGEXP — поиск по шаблону (MySQL, PostgreSQL)
Когда LIKE не справляется, можно использовать REGEXP для гибкого поиска по регулярным выражениям.
✅ Пример:
SELECT * FROM users
WHERE name REGEXP '^Андрей|^Алексей';
🔹 Почему? Найдёт всех, чьё имя начинается с «Андрей» или «Алексей».
4️⃣ LATERAL — динамические подзапросы (PostgreSQL, Oracle)
Позволяет передавать данные из одного запроса в другой внутри JOIN.
✅ Пример:
SELECT u.name, o.order_date
FROM users u
JOIN LATERAL (SELECT * FROM orders WHERE orders.user_id = u.id LIMIT 1) o ON true;
🔹 Почему? Покажет только один последний заказ для каждого пользователя.
📌 Вывод:
⚡️ COALESCE спасает от NULL
⚡️ INSERT IGNORE предотвращает ошибки вставки
⚡️ REGEXP расширяет возможности поиска
⚡️ LATERAL даёт гибкость подзапросам
💡 Знал ли ты о всех этих командах? Делись в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #DML
👍7🔥6💯4
🔥 7 ОШИБОК В SQL, КОТОРЫЕ МОГУТ СТОИТЬ КАРЬЕРЫ
SQL — это не просто язык запросов, а мощный инструмент управления данными. Но если им пользоваться неправильно, база может тормозить, данные потеряются, а коллеги будут недовольны. Разберем частые ошибки.
1️⃣ Использовать SELECT * в продакшене
⚠️ Почему это плохо?
🔹 Забирает всю таблицу, даже если нужны 2-3 колонки
🔹 Ломает код при изменении структуры таблицы
🔹 Усложняет работу оптимизатора запросов
✅ Как правильно?
Выбираем только нужные столбцы:
Если нужно получить все столбцы динамически — лучше заранее уточнить их в коде приложения.
Гайд по команде тут
2️⃣ Игнорировать индексы на больших таблицах
⚠️ Почему это плохо?
🔹 Запросы без индексов работают в десятки раз медленнее
🔹 БД вынуждена сканировать всю таблицу
🔹 Производительность падает на глазах
✅ Как правильно?
Добавляем индекс на часто используемые столбцы (например, при фильтрации по salary):
💡 Но не переусердствуй! Лишние индексы замедляют INSERT и UPDATE.
Пост про индексы тут
3️⃣ Хранить пароли в открытом виде
⚠️ Почему это плохо?
🔹Любая утечка данных = утечка всех паролей пользователей
🔹 Это критическая уязвимость
✅ Как правильно?
Пароли всегда хэшируются перед сохранением. Никогда не храни их в открытом виде!
💡 Лучше использовать bcrypt или argon2, так как они более надёжны, чем SHA2.
4️⃣ Забывать про транзакции при изменении данных
⚠️ Почему это плохо?
🔹 Если процесс прервётся, часть данных может остаться несохранённой
🔹 Без ROLLBACK нельзя откатить ошибочные изменения
✅ Как правильно?
Используем транзакции при изменении нескольких таблиц сразу:
💡 Если что-то пошло не так, можно откатить изменения:
Всегда используй COMMIT только тогда, когда уверен, что всё прошло успешно!
5️⃣ Запускать тяжёлые запросы без EXPLAIN
⚠️ Почему это плохо?
🔹 Запрос может внезапно зависнуть на часы
🔹 Может заблокировать всю базу для других пользователей
✅ Как правильно?
Перед выполнением сложного запроса проверяем его план выполнения:
💡 Что важно проверить?
🔹Есть ли Table Scan (это плохо, нужен индекс)
🔹Использует ли SQL ключи и индексы
🔹Какое количество строк реально обрабатывается
6️⃣ Забывать LIMIT при DELETE и UPDATE
⚠️ Почему это плохо?
🔹Если случайно забыть WHERE, можно удалить ВСЕ данные 😱
🔹Один неверный UPDATE может затронуть миллионы строк
✅ Как правильно?
Ограничиваем DELETE и UPDATE, чтобы не изменить слишком много строк:
Пример с лимитами для DELETE:
Пример с лимитами для UPDATE:
💡 В PostgreSQL LIMIT в UPDATE и DELETE не работает. Используй WHERE id IN (SELECT id FROM table LIMIT X).
7️⃣ Злоупотреблять NULL в таблицах
⚠️ Почему это плохо?
🔹NULL ломает агрегатные функции (SUM, AVG)
🔹NULL усложняет условия в JOIN и WHERE
🔹Фильтрация NULL требует специальных проверок (IS NULL, а не =)
✅ Как правильно?
Если NULL можно избежать, используй значения по умолчанию:
💡 Если NULL неизбежен (например, у поля middle_name), всегда пиши COALESCE, чтобы избежать сюрпризов:
Подробнее про COALESCE тут
🔥 Вывод:
Эти ошибки встречаются даже у опытных разработчиков. Теперь ты знаешь, как их избежать!
💬 Какие ошибки ты встречал чаще всего? Пиши в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #Оптимизация_SQL #Ошибки_SQL
SQL — это не просто язык запросов, а мощный инструмент управления данными. Но если им пользоваться неправильно, база может тормозить, данные потеряются, а коллеги будут недовольны. Разберем частые ошибки.
1️⃣ Использовать SELECT * в продакшене
⚠️ Почему это плохо?
🔹 Забирает всю таблицу, даже если нужны 2-3 колонки
🔹 Ломает код при изменении структуры таблицы
🔹 Усложняет работу оптимизатора запросов
✅ Как правильно?
Выбираем только нужные столбцы:
SELECT id, name, salary FROM employees;
Если нужно получить все столбцы динамически — лучше заранее уточнить их в коде приложения.
Гайд по команде тут
2️⃣ Игнорировать индексы на больших таблицах
⚠️ Почему это плохо?
🔹 Запросы без индексов работают в десятки раз медленнее
🔹 БД вынуждена сканировать всю таблицу
🔹 Производительность падает на глазах
✅ Как правильно?
Добавляем индекс на часто используемые столбцы (например, при фильтрации по salary):
CREATE INDEX idx_salary ON employees(salary);
💡 Но не переусердствуй! Лишние индексы замедляют INSERT и UPDATE.
Пост про индексы тут
3️⃣ Хранить пароли в открытом виде
⚠️ Почему это плохо?
🔹Любая утечка данных = утечка всех паролей пользователей
🔹 Это критическая уязвимость
✅ Как правильно?
Пароли всегда хэшируются перед сохранением. Никогда не храни их в открытом виде!
INSERT INTO users (username, password)
VALUES ('admin', SHA2('mysecretpass', 256));
💡 Лучше использовать bcrypt или argon2, так как они более надёжны, чем SHA2.
4️⃣ Забывать про транзакции при изменении данных
⚠️ Почему это плохо?
🔹 Если процесс прервётся, часть данных может остаться несохранённой
🔹 Без ROLLBACK нельзя откатить ошибочные изменения
✅ Как правильно?
Используем транзакции при изменении нескольких таблиц сразу:
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
💡 Если что-то пошло не так, можно откатить изменения:
ROLLBACK;
Всегда используй COMMIT только тогда, когда уверен, что всё прошло успешно!
5️⃣ Запускать тяжёлые запросы без EXPLAIN
⚠️ Почему это плохо?
🔹 Запрос может внезапно зависнуть на часы
🔹 Может заблокировать всю базу для других пользователей
✅ Как правильно?
Перед выполнением сложного запроса проверяем его план выполнения:
EXPLAIN ANALYZE SELECT * FROM orders WHERE total > 10000;
💡 Что важно проверить?
🔹Есть ли Table Scan (это плохо, нужен индекс)
🔹Использует ли SQL ключи и индексы
🔹Какое количество строк реально обрабатывается
6️⃣ Забывать LIMIT при DELETE и UPDATE
⚠️ Почему это плохо?
🔹Если случайно забыть WHERE, можно удалить ВСЕ данные 😱
🔹Один неверный UPDATE может затронуть миллионы строк
✅ Как правильно?
Ограничиваем DELETE и UPDATE, чтобы не изменить слишком много строк:
Пример с лимитами для DELETE:
DELETE FROM logs WHERE created_at < NOW() - INTERVAL 30 DAY LIMIT 1000;
Пример с лимитами для UPDATE:
UPDATE employees SET salary = salary * 1.1 WHERE department = 'IT' LIMIT 500;
💡 В PostgreSQL LIMIT в UPDATE и DELETE не работает. Используй WHERE id IN (SELECT id FROM table LIMIT X).
7️⃣ Злоупотреблять NULL в таблицах
⚠️ Почему это плохо?
🔹NULL ломает агрегатные функции (SUM, AVG)
🔹NULL усложняет условия в JOIN и WHERE
🔹Фильтрация NULL требует специальных проверок (IS NULL, а не =)
✅ Как правильно?
Если NULL можно избежать, используй значения по умолчанию:
ALTER TABLE users ALTER COLUMN email SET DEFAULT 'не указан';
💡 Если NULL неизбежен (например, у поля middle_name), всегда пиши COALESCE, чтобы избежать сюрпризов:
SELECT COALESCE(middle_name, '—') FROM users;
Подробнее про COALESCE тут
🔥 Вывод:
Эти ошибки встречаются даже у опытных разработчиков. Теперь ты знаешь, как их избежать!
💬 Какие ошибки ты встречал чаще всего? Пиши в комментариях!
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Операторы_и_работа_с_данными
#SQL #Оптимизация_SQL #Ошибки_SQL
🔥9👍5💯4
🗄 Типы данных в SQL: основы
Типы данных – это фундаментальная часть SQL, влияющая на DML (манипуляции данными) и DDL (структура базы). Они определяют, как хранятся, обрабатываются и извлекаются данные, а неправильный выбор может привести к проблемам с производительностью, точностью и хранением. Тип данных задается при создании таблиц.
1️⃣ Числовые типы
SQL поддерживает два основных вида чисел: целые и дробные.
✔️Целые (INTEGER, SMALLINT, BIGINT) — подходят для хранения чисел без дробной части, например, идентификаторов или количественных данных.
✔️Дробные (DECIMAL, NUMERIC, FLOAT, REAL) — используются для финансовых расчётов и значений с плавающей точкой.
⚠️Важно! FLOAT и REAL могут терять точность из-за особенностей работы с плавающей точкой. Для финансовых операций лучше использовать DECIMAL.
2️⃣ Строковые типы
Строки хранят текстовую информацию, но выбор неправильного типа может повлиять на эффективность.
✔️CHAR(N) — фиксированная длина строки, используется, если длина всегда одинаковая (например, коды стран).
✔️VARCHAR(N) — переменная длина, подходит для большинства текстовых данных.
✔️TEXT или CLOB — для хранения больших текстов (например, описаний или комментариев).
⚠️Важно! TEXT не индексируется напрямую в большинстве СУБД, поэтому его лучше использовать для больших объемов данных, но не для поиска.
3️⃣ Даты и время
Работа со временем в SQL требует понимания разных типов:
✔️DATE — хранит только дату (год, месяц, день).
✔️TIME — хранит только время (часы, минуты, секунды).
✔️TIMESTAMP — объединяет дату и время, может учитывать часовой пояс.
📌 Совет! Для работы с временными зонами, особенно если система поддерживает пользователей из разных регионов, лучше использовать TIMESTAMP WITH TIME ZONE, если это поддерживается в вашей СУБД.
4️⃣ Хранение сложных данных
Современные базы данных позволяют хранить не только числа и строки:
✔️JSON — полезен для структурированных данных, например, в PostgreSQL (jsonb) и MySQL.
✔️XML — используется в корпоративных системах, где требуется строгая структура данных.
📌 Совет! Если часто требуется поиск по JSON, лучше выбирать jsonb в PostgreSQL, так как он индексируется.
Пример создания таблицы с разными типами данных (помним, что создание таблиц в БД это подъязык SQL - DDL)
Разбор типов данных из примера:
✔️ INTEGER — идентификатор, удобен для автоинкремента.
✔️ VARCHAR(255) — хранит строки переменной длины, используется для наименований.
✔️ TEXT — предназначен для больших текстов (например, описание товаров).
✔️ DECIMAL(10,2) — важен для хранения денежных значений, исключает ошибки округления.
✔️ SMALLINT — экономит место, если числовые значения небольшие.
✔️ TIMESTAMP — фиксирует дату и время, можно использовать для аудита изменений.
✔️ BOOLEAN — хранит логические значения, удобен для активных/неактивных элементов.
✔️ JSON — подходит для хранения неструктурированных данных (например, дополнительных характеристик товара).
🔥 Вывод:
Выбор типа данных влияет на размер базы, скорость запросов и корректность вычислений. Ошибки могут привести к избыточному хранению, потерям точности и проблемам с производительностью.
#Операторы_и_работа_с_данными #SQL #Типы_данных
Типы данных – это фундаментальная часть SQL, влияющая на DML (манипуляции данными) и DDL (структура базы). Они определяют, как хранятся, обрабатываются и извлекаются данные, а неправильный выбор может привести к проблемам с производительностью, точностью и хранением. Тип данных задается при создании таблиц.
1️⃣ Числовые типы
SQL поддерживает два основных вида чисел: целые и дробные.
✔️Целые (INTEGER, SMALLINT, BIGINT) — подходят для хранения чисел без дробной части, например, идентификаторов или количественных данных.
✔️Дробные (DECIMAL, NUMERIC, FLOAT, REAL) — используются для финансовых расчётов и значений с плавающей точкой.
⚠️Важно! FLOAT и REAL могут терять точность из-за особенностей работы с плавающей точкой. Для финансовых операций лучше использовать DECIMAL.
2️⃣ Строковые типы
Строки хранят текстовую информацию, но выбор неправильного типа может повлиять на эффективность.
✔️CHAR(N) — фиксированная длина строки, используется, если длина всегда одинаковая (например, коды стран).
✔️VARCHAR(N) — переменная длина, подходит для большинства текстовых данных.
✔️TEXT или CLOB — для хранения больших текстов (например, описаний или комментариев).
⚠️Важно! TEXT не индексируется напрямую в большинстве СУБД, поэтому его лучше использовать для больших объемов данных, но не для поиска.
3️⃣ Даты и время
Работа со временем в SQL требует понимания разных типов:
✔️DATE — хранит только дату (год, месяц, день).
✔️TIME — хранит только время (часы, минуты, секунды).
✔️TIMESTAMP — объединяет дату и время, может учитывать часовой пояс.
📌 Совет! Для работы с временными зонами, особенно если система поддерживает пользователей из разных регионов, лучше использовать TIMESTAMP WITH TIME ZONE, если это поддерживается в вашей СУБД.
4️⃣ Хранение сложных данных
Современные базы данных позволяют хранить не только числа и строки:
✔️JSON — полезен для структурированных данных, например, в PostgreSQL (jsonb) и MySQL.
✔️XML — используется в корпоративных системах, где требуется строгая структура данных.
📌 Совет! Если часто требуется поиск по JSON, лучше выбирать jsonb в PostgreSQL, так как он индексируется.
Пример создания таблицы с разными типами данных (помним, что создание таблиц в БД это подъязык SQL - DDL)
CREATE TABLE products (
product_id INTEGER PRIMARY KEY, -- Целочисленный идентификатор товара
name VARCHAR(255), -- Название товара, переменная строка
denoscription TEXT, -- Описание товара, длинный текст
price DECIMAL(10,2), -- Цена товара с двумя знаками после запятой
stock_quantity SMALLINT, -- Количество товара в наличии, небольшое целое число
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- Дата и время создания записи
updated_at TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -- Дата и время последнего обновления
is_active BOOLEAN DEFAULT TRUE, -- Флаг активности товара (true/false)
metadata JSON -- Дополнительные данные в JSON-формате (если поддерживается СУБД)
);
Разбор типов данных из примера:
✔️ INTEGER — идентификатор, удобен для автоинкремента.
✔️ VARCHAR(255) — хранит строки переменной длины, используется для наименований.
✔️ TEXT — предназначен для больших текстов (например, описание товаров).
✔️ DECIMAL(10,2) — важен для хранения денежных значений, исключает ошибки округления.
✔️ SMALLINT — экономит место, если числовые значения небольшие.
✔️ TIMESTAMP — фиксирует дату и время, можно использовать для аудита изменений.
✔️ BOOLEAN — хранит логические значения, удобен для активных/неактивных элементов.
✔️ JSON — подходит для хранения неструктурированных данных (например, дополнительных характеристик товара).
🔥 Вывод:
Выбор типа данных влияет на размер базы, скорость запросов и корректность вычислений. Ошибки могут привести к избыточному хранению, потерям точности и проблемам с производительностью.
#Операторы_и_работа_с_данными #SQL #Типы_данных
🔥10👍4💯4
💾 Реляционная модель данных: теория и принципы
Реляционная модель данных – это способ организации и представления данных в виде таблиц (или отношений). Она была предложена Эдгаром Ф. Коддом в 1970 году и стала основой для большинства современных систем управления базами данных (СУБД), таких как MySQL, PostgreSQL, Oracle, SQL Server.
В реляционной модели данные хранятся в виде таблиц (relations), а каждая строка в таблице представляет собой запись (tuple), содержащую значения атрибутов (столбцов).
💾 Основные компоненты реляционной модели:
1️⃣ Отношение (Relation) = Таблица.
Основная структура хранения данных.
Состоит из строк (кортежей) и столбцов (атрибутов).
2️⃣ Атрибут (Attribute) = Столбец таблицы.
Определяет характеристику сущности (например, «Имя», «Цена», «Дата»).
Каждый атрибут имеет свой тип данных (INTEGER, VARCHAR, DATE и т. д.).
3️⃣ Кортеж (Tuple) = Строка в таблице.
Представляет собой один экземпляр сущности (например, одну запись о клиенте).
4️⃣ Домен (Domain) = Диапазон допустимых значений для атрибута.
Например, для атрибута «Возраст» допустимы только целые числа от 0 до 120.
5️⃣ Первичный ключ (Primary Key, PK)
Уникальный идентификатор строки в таблице (например, ID клиента).
6️⃣ Внешний ключ (Foreign Key, FK)
Ссылка на первичный ключ другой таблицы, создающая связь между таблицами.
💾 Принципы реляционной модели
1️⃣ Единообразное представление данных.
Все данные хранятся в виде таблиц, каждая из которых представляет сущность.
2️⃣ Уникальность строк.
Каждая строка (запись) в таблице должна быть уникальной и идентифицироваться первичным ключом.
3️⃣ Отсутствие повторяющихся данных (нормализация).
Повторяющиеся данные должны минимизироваться путём разбиения на связанные таблицы.
4️⃣ Целостность данных.
1. Сущностная целостность – каждый кортеж должен иметь уникальный первичный ключ.
2. Ссылочная целостность – внешний ключ должен ссылаться на существующую запись.
3. Доменная целостность – данные должны соответствовать определённому типу.
5️⃣ Манипуляции с данными через SQL.
Язык SQL используется для выполнения операций над таблицами и управления БД (SELECT, INSERT, UPDATE, DELETE и прочее).
💾 Связи между таблицами
Реляционная модель позволяет строить связи между таблицами:
1️⃣ Один ко многим (1:M)
1. Например, один клиент может иметь несколько заказов.
2. Внешний ключ в таблице заказов ссылается на первичный ключ клиента.
2️⃣ Многие ко многим (M:N)
1. Например, один студент может записаться на несколько курсов, и каждый курс может включать многих студентов.
2. Решается через промежуточную таблицу.
3️⃣ Один к одному (1:1)
Например, один сотрудник может иметь один личный кабинет.
🔹 Преимущества реляционной модели
✅ Гибкость – легко изменять и расширять структуру базы.
✅ Целостность – строгие ограничения предотвращают ошибки и дублирование данных.
✅ Эффективность запросов – возможность использования индексов, оптимизации SQL-запросов.
✅ Универсальность – подходит для большинства бизнес-приложений.
🔹 Недостатки реляционной модели
❌ Производительность на больших объёмах данных – при очень больших данных (миллиарды записей) NoSQL-решения могут быть быстрее.
❌ Сложность масштабирования – горизонтальное масштабирование сложнее, чем в NoSQL.
❌ Жёсткость схемы – структура таблиц фиксирована, что требует продуманного проектирования.
🔥 Вывод
Реляционная модель данных остаётся основным стандартом хранения структурированной информации. Она обеспечивает надёжность, удобство работы и точность данных. Однако, для больших распределённых систем могут использоваться альтернативные модели, такие как NoSQL (документные, графовые, колонночные базы).
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Реляционные_базы_данных #SQL
Реляционная модель данных – это способ организации и представления данных в виде таблиц (или отношений). Она была предложена Эдгаром Ф. Коддом в 1970 году и стала основой для большинства современных систем управления базами данных (СУБД), таких как MySQL, PostgreSQL, Oracle, SQL Server.
В реляционной модели данные хранятся в виде таблиц (relations), а каждая строка в таблице представляет собой запись (tuple), содержащую значения атрибутов (столбцов).
💾 Основные компоненты реляционной модели:
1️⃣ Отношение (Relation) = Таблица.
Основная структура хранения данных.
Состоит из строк (кортежей) и столбцов (атрибутов).
2️⃣ Атрибут (Attribute) = Столбец таблицы.
Определяет характеристику сущности (например, «Имя», «Цена», «Дата»).
Каждый атрибут имеет свой тип данных (INTEGER, VARCHAR, DATE и т. д.).
3️⃣ Кортеж (Tuple) = Строка в таблице.
Представляет собой один экземпляр сущности (например, одну запись о клиенте).
4️⃣ Домен (Domain) = Диапазон допустимых значений для атрибута.
Например, для атрибута «Возраст» допустимы только целые числа от 0 до 120.
5️⃣ Первичный ключ (Primary Key, PK)
Уникальный идентификатор строки в таблице (например, ID клиента).
6️⃣ Внешний ключ (Foreign Key, FK)
Ссылка на первичный ключ другой таблицы, создающая связь между таблицами.
💾 Принципы реляционной модели
1️⃣ Единообразное представление данных.
Все данные хранятся в виде таблиц, каждая из которых представляет сущность.
2️⃣ Уникальность строк.
Каждая строка (запись) в таблице должна быть уникальной и идентифицироваться первичным ключом.
3️⃣ Отсутствие повторяющихся данных (нормализация).
Повторяющиеся данные должны минимизироваться путём разбиения на связанные таблицы.
4️⃣ Целостность данных.
1. Сущностная целостность – каждый кортеж должен иметь уникальный первичный ключ.
2. Ссылочная целостность – внешний ключ должен ссылаться на существующую запись.
3. Доменная целостность – данные должны соответствовать определённому типу.
5️⃣ Манипуляции с данными через SQL.
Язык SQL используется для выполнения операций над таблицами и управления БД (SELECT, INSERT, UPDATE, DELETE и прочее).
💾 Связи между таблицами
Реляционная модель позволяет строить связи между таблицами:
1️⃣ Один ко многим (1:M)
1. Например, один клиент может иметь несколько заказов.
2. Внешний ключ в таблице заказов ссылается на первичный ключ клиента.
2️⃣ Многие ко многим (M:N)
1. Например, один студент может записаться на несколько курсов, и каждый курс может включать многих студентов.
2. Решается через промежуточную таблицу.
3️⃣ Один к одному (1:1)
Например, один сотрудник может иметь один личный кабинет.
🔹 Преимущества реляционной модели
✅ Гибкость – легко изменять и расширять структуру базы.
✅ Целостность – строгие ограничения предотвращают ошибки и дублирование данных.
✅ Эффективность запросов – возможность использования индексов, оптимизации SQL-запросов.
✅ Универсальность – подходит для большинства бизнес-приложений.
🔹 Недостатки реляционной модели
❌ Производительность на больших объёмах данных – при очень больших данных (миллиарды записей) NoSQL-решения могут быть быстрее.
❌ Сложность масштабирования – горизонтальное масштабирование сложнее, чем в NoSQL.
❌ Жёсткость схемы – структура таблиц фиксирована, что требует продуманного проектирования.
🔥 Вывод
Реляционная модель данных остаётся основным стандартом хранения структурированной информации. Она обеспечивает надёжность, удобство работы и точность данных. Однако, для больших распределённых систем могут использоваться альтернативные модели, такие как NoSQL (документные, графовые, колонночные базы).
💡Курс от автора канала на Stepik с сертификатом
"DDL в SQL: Определение и управление структурами баз данных"
При переходе по данной ссылке скидка 50%
#Реляционные_базы_данных #SQL
🔥11👍5💯4👾1
🔍 Функция CASE – условные конструкции в SQL
Функция CASE работает аналогично if-else в языках программирования. Она позволяет проверять условия и возвращать разные значения в зависимости от их выполнения.
Как работает?
SQL проверяет условия WHEN сверху вниз. Как только условие выполнено, возвращается соответствующее значение THEN. Если ни одно из условий не выполнено, используется ELSE (если он указан).
Пример:
Классифицируем сотрудников по уровню зарплаты.
Допустим, у нас есть следующая таблица employees:
Подготовим запрос для классификации:
Логически функция CASE из данного запроса выглядит так:
После выполнения запроса база данных вернёт следующий результат:
Что происходит?
WHEN 1 - если salary больше 5000 – в столбец salary_category записывается 'Высокая зарплата'
WHEN 2 - если salary от 3000 до 5000 – записывается 'Средняя зарплата'
ELSE - если ни одно из условий не выполнено – записывается 'Низкая зарплата'
Где полезно?
✔️Создание категорий (например, разделение клиентов по уровню покупок).
✔️Генерация текстовых описаний на основе данных.
✔️Гибкая обработка данных прямо в SQL-запросе без изменения исходной таблицы.
#Операторы_и_работа_с_данными #CASE
Подписаться на канал
Функция CASE работает аналогично if-else в языках программирования. Она позволяет проверять условия и возвращать разные значения в зависимости от их выполнения.
Как работает?
SQL проверяет условия WHEN сверху вниз. Как только условие выполнено, возвращается соответствующее значение THEN. Если ни одно из условий не выполнено, используется ELSE (если он указан).
Пример:
Классифицируем сотрудников по уровню зарплаты.
Допустим, у нас есть следующая таблица employees:
name salary
Иван 6000
Ольга 4500
Алексей 3000
Мария 2000
Подготовим запрос для классификации:
SELECT name,
salary,
CASE
WHEN salary > 5000 THEN 'Высокая зарплата'
WHEN salary BETWEEN 3000 AND 5000 THEN 'Средняя зарплата'
ELSE 'Низкая зарплата'
END AS salary_category
FROM employees;
Логически функция CASE из данного запроса выглядит так:
CASE
WHEN -- условие 1
WHEN -- условие 2
ELSE -- иначе, если не соблюдены условия
END AS -- пользовательское название столбца для записи результатов
После выполнения запроса база данных вернёт следующий результат:
name salary salary_category
Иван 6000 Высокая зарплата
Ольга 4500 Средняя зарплата
Алексей 3000 Средняя зарплата
Мария 2000 Низкая зарплата
Что происходит?
WHEN 1 - если salary больше 5000 – в столбец salary_category записывается 'Высокая зарплата'
WHEN 2 - если salary от 3000 до 5000 – записывается 'Средняя зарплата'
ELSE - если ни одно из условий не выполнено – записывается 'Низкая зарплата'
Где полезно?
✔️Создание категорий (например, разделение клиентов по уровню покупок).
✔️Генерация текстовых описаний на основе данных.
✔️Гибкая обработка данных прямо в SQL-запросе без изменения исходной таблицы.
#Операторы_и_работа_с_данными #CASE
Подписаться на канал
🔥11💯3👾3
Какой результат вернёт следующий запрос, если salary = 3500? (теория в посте выше)
#тест
SELECT CASE
WHEN salary > 5000 THEN 'Высокая зарплата'
WHEN salary BETWEEN 3000 AND 5000 THEN 'Средняя зарплата'
ELSE 'Низкая зарплата'
END AS salary_category;
#тест
👾6🔥3