Базы Данных (Data Base) | SQL & NoSQL. PostgreSQL, MySQL и Big Data. Уроки для Backend и Data Engineer. Архитектура БД, Оптимизация и Design.

Postgres против MySQL.

Postgres спроектирован как единая, целостная система, и этот архитектурный подход определяет принципы работы всех остальных компонентов.

Данные хранятся в виде «кучи» (heap), где могут одновременно существовать несколько версий одной и той же строки. При обновлении создаются новые версии, а старые сохраняются до тех пор, пока не будут удалены в процессе очистки (VACUUM). Механизм MVCC (многоверсионное управление параллельным доступом) встроен непосредственно в модель данных, что открывает широкие возможности для индексации и расширения функциональности.

В основе MySQL лежит архитектура с подключаемыми модулями хранения (storage engines).

Уровень SQL находится «сверху», а за хранение данных отвечает движок InnoDB. Старые версии строк хранятся в журналах отката (undo logs) и восстанавливаются по мере необходимости. Данные организованы в виде кластеризованного индекса, где первичный ключ определяет их физическое расположение.

#db

👉 @database_info

Что происходит с идеей после хакатона?

На ЛЦТ.Фесте участники конкурса «Лидеры цифровой трансформации» представят свои разработки для города и бизнеса. А эксперты и представители технологических компаний расскажут об опыте создания и внедрения цифровых решений.

Гостей ждут лекции, дискуссии, интерактивные площадки и новые знакомства. Студенты ИТ- и инженерных направлений смогут познакомиться с задачами индустрии, специалисты найдут темы для профессионального обсуждения, а все, кому интересны современные цифровые разработки России, узнают больше о технологиях и их применении. А ещё узнаем, кто разделит призовой фонд хакатона «Лидеры цифровой трансформации» в 40 млн рублей.

📍 30 октября, кластер «Ломоносов», Москва

❗️Вход свободный по предварительной регистрации. Количество мест ограничено, регистрируйтесь заранее по ссылке

🛑 Антипаттерн: "Списки через запятую" в базе данных

Признайтесь, у каждого был соблазн сделать это. У вас есть сущность (например, User), и нужно сохранить список их ролей или IDs купленных товаров. Создавать отдельную таблицу кажется оверхедом, и вы решаете: "А, запишу просто строкой через запятую".

В БД это выглядит так:
role_ids: "1,4,12"

Почему это бомба замедленного действия и как это лечить? Давайте разбираться.

Почему это плохо (The Pain):

1. Сложный поиск. Найти всех пользователей с role_id = 1 через LIKE '%1%' - это больно. Вы найдете и 1, и 12, и 100. Придется писать монструозные регулярки.

2. Никаких индексов. База данных не может эффективно индексировать подстроки в таком формате. Full scan обеспечен.

3. Проблемы с JOIN. Вы не сможете сделать нормальный JOIN с таблицей ролей.

4. Целостность данных. Вы не можете повесить Foreign Key. Никто не помешает записать туда "1, 4, apple, NULL".

5. Атомарность обновлений. Удалить роль 4 из строки "1,4,12" - это чтение, парсинг на бекенде и перезапись. Состояние гонки (race condition) гарантировано.

Как делать правильно:

Вариант 1: Классическая нормализация (Junction Table)
Создайте связующую таблицу. Это золотой стандарт для реляционных БД (PostgreSQL, MySQL, Oracle).

-- Плохо ❌
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(50),
role_ids VARCHAR(255) -- "1,2"
);

-- Хорошо ✅
CREATE TABLE user_roles (
user_id INT,
role_id INT,
PRIMARY KEY (user_id, role_id),
FOREIGN KEY (user_id) REFERENCES users(id),
FOREIGN KEY (role_id) REFERENCES roles(id)
);

Теперь выборка всех админов - это моментальный запрос с использованием индексов.

Вариант 2: Массивы или JSONB (PostgreSQL)
Если вы используете PostgreSQL и вам действительно не нужны жесткие FK (Foreign Keys) на каждый элемент, можно использовать нативные типы.

-- Допустимо в Postgres ✅
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT,
role_ids INT[] -- массив целых чисел
);

-- Поиск (очень быстрый с GIN индексом):
SELECT * FROM users WHERE 1 = ANY(role_ids);

Никогда не храните списки в VARCHAR, если вам когда-либо придется искать по содержимому этого списка или джойнить его. Экономия 5 минут на старте обернется часами рефакторинга позже.

#db

👉 @database_info