🔹 Что такое NULL в SQL и как с ним работать?

В SQL NULL означает отсутствие значения. Это не ноль и не пустая строка, а именно неизвестное значение.

NULL в SQL может приводить к неожиданным ошибкам и неправильным результатам, если его не учитывать.

📌 Как проверить NULL?
Обычное сравнение (= NULL) не работает! Используй IS NULL:

SELECT * FROM users WHERE email IS NULL;

🔹 Выбирает всех пользователей, у которых нет e-mail.

📌 Как заменить NULL на другое значение?
Используй COALESCE или IFNULL:

SELECT name, COALESCE(email, 'Не указан') AS email 
FROM users;

🔹 Если email NULL, вместо него выведется значение 'Не указан'.

📌 Как избежать NULL в новых данных?
При создании таблицы можно запретить NULL в колонке:

CREATE TABLE users (
    id INT PRIMARY KEY, 
    name VARCHAR(100) NOT NULL);

🔹 Теперь name обязательно нужно заполнять.

💡 Вывод:
✔️ NULL – это отсутствие значения.
✔️ Проверяй NULL через IS NULL.
✔️ Используй COALESCE для замены NULL.

❓ А ты всегда учитываешь NULL в своих запросах?

#Операторы_и_работа_с_данными
#SQL #NULL #ОсновыSQL #ИТ

Как работает GROUP BY в SQL?

GROUP BY – это оператор, который группирует строки с одинаковыми значениями в одну и позволяет применять агрегатные функции, такие как COUNT, SUM, AVG, MIN, MAX.

📌 Простой пример: Посчитаем, сколько сотрудников в каждом отделе:

SELECT department, COUNT(*) AS employee_count 
FROM employees 
GROUP BY department;

🔹 SQL объединит всех сотрудников с одинаковым department и посчитает их количество.

📌 Использование с другими агрегатными функциями:

SELECT department, AVG(salary) AS avg_salary, MAX(salary) AS max_salary 
FROM employees 
GROUP BY department;

🔹 Покажет среднюю (AVG) и максимальную (MAX) зарплату по отделам.

📌 Фильтрация после GROUP BY – HAVING
Если нужно оставить только отделы со средней зарплатой выше 50 000:

SELECT department, AVG(salary) AS avg_salary 
FROM employees 
GROUP BY department 
HAVING AVG(salary) > 50000;

🔹 HAVING фильтрует уже сгруппированные данные (в отличие от WHERE, который фильтрует до группировки).

⚡️ Вывод:
✔️ GROUP BY группирует строки по указанному полю.
✔️ Без агрегатной функции группировка не имеет смысла.
✔️ HAVING используется для фильтрации сгруппированных данных.

❓ Ты часто используешь GROUP BY в своих запросах?

#Операторы_и_работа_с_данными
#SQL #GROUP_BY #DML #ИТ

🔹 5 главных ошибок при работе с 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

🔹 Основы SELECT в SQL – с чего начать?

Оператор 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
#ИТ

🔹 Что такое первичный ключ (PRIMARY KEY) в SQL?

Первичный ключ (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

🔹 Внешний ключ (FOREIGN KEY)

Внешний ключ (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

🔥 HAVING vs WHERE – в чём разница?

Если ты фильтруешь данные в 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

🔥 Индексы в SQL: ускоряем запросы к БД

Индексы – это ускорители поиска в базе данных. Без них 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

🔥 SQL-подзапросы: мощный инструмент в одном запросе!

Подзапрос (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

💾 Освойте DDL в SQL и станьте мастером управления структурами БД!

🔥Хотите уверенно проектировать и администрировать реляционные базы данных?

Курс Stepik от автора данного канала Владимира Лунева "DDL в SQL: Определение и управление структурами баз данных" поможет вам разобраться во всех аспектах создания, изменения и удаления объектов БД!

Подписчикам канала скидка на курс 50% по промокоду - RELATIONAL

📚 Что вас ждет?
✅ Сертификат Stepik после окончания курса.
✅ 8 модулей с теорией и практическими заданиями
✅ Глубокое понимание практической работы с реляционными базами данных
✅ Работа с таблицами, ключами, ограничениями, схемами и представлениями, триггерами и правами доступа
✅ Освоение команд CREATE, ALTER, DROP и других возможностей DDL

💡 Этот курс – ваш путь к профессиональному росту в SQL! Независимо от уровня подготовки, вы получите структурированные знания и практику.

https://stepik.org/232192

Присоединяйтесь и прокачайте свои навыки!

#SQL #DDL #БазыДанных #Программирование #IT

🔥 JOIN vs. SUBQUERY: что лучше?

В 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

🔥 Как 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 #ИТ

🔥 Гайд - SELECT на практике: разбор с примерами 📊

Оператор 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

📝 INSERT в SQL: добавляем данные правильно!

Оператор 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

🔄 UPDATE в SQL: как обновлять данные правильно?

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

🗑 Удаление данных в SQL: основы DELETE

Удаление данных — важная часть работы с БД. В 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

🔥10 ОШИБОК В 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

🔥 Необычные SQL-команды, о которых знают не все!

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 ОШИБОК В 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

🗄 Типы данных в 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 #Типы_данных

💾 Реляционная модель данных: теория и принципы

Реляционная модель данных – это способ организации и представления данных в виде таблиц (или отношений). Она была предложена Эдгаром Ф. Коддом в 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