Телеграм канал «Базы данных (Data Base)»

Postgres против MySQL.

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

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

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

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

📲 Мы в MAX

#db

👉 @database_info

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

Признайтесь, у каждого был соблазн сделать это. У вас есть сущность (например, 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 минут на старте обернется часами рефакторинга позже.


📲 Мы в MAX

#db

👉 @database_info

PostgreSQL или MySQL?

Один из самых частых вопросов от разработчиков и DevOps - “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇

🔷 PostgreSQL:

🔵Поддержка JSONB с индексами - почти как NoSQL внутри SQL
🔵CTE, оконные функции, полнотекстовый поиск - топ для аналитики
🔵Расширяемость: можно писать свои типы, функции, операторы
🔵Хорош для сложных запросов, аналитики, геоданных (PostGIS)

🔻 Минусы:
– Сложнее в настройке и оптимизации
– Меньше хостингов out-of-the-box (но всё быстро меняется)


🔶 MySQL (особенно InnoDB / MariaDB):

🔵Быстрее на простых SELECT/INSERT, если запросы примитивные
🔵Больше ready-to-go хостингов и тулов для web
🔵Низкий порог входа - быстрее поднимается новичками

🔻 Минусы:
– Слабее в сложных SQL-конструкциях
– Нет нормальной поддержки CTE до недавнего времени
– JSON без индексации (в MySQL < 8.0)


Вывод:
🧠 Если делаешь CRM, веб-продукт или MVP с простыми запросами, MySQL зайдёт.

📊 Если строишь data-heavy приложения, BI, ETL или гео-системы, PostgreSQL без шансов.

📲 Мы в MAX

#db

👉 @database_info

💣 NULL — тихий саботаж в твоей БД

На первый взгляд, NULL — просто отсутствие значения. Но на практике это частый источник багов, неверных аналитик и проблем в бизнес-логике.

📉 Антипаттерн: беспечное обращение с NULL

Примеры:


SELECT * FROM users WHERE age > 18; -- Пользователи с age = NULL не попадут


Ты думаешь, что отбираешь всех взрослых, но age = NULL тут "выпадает", ведь NULL > 18 → UNKNOWN.


WHERE col1 = col2 -- Не сработает, если хотя бы одно значение NULL


🙈 Проблема: NULL не равно даже самому себе (NULL != NULL).
📉 Итоги: ошибки в JOIN'ах, WHERE-фильтрах, расчетах.



🛡 Как защититься:

✅ Явно учитывай NULL:


WHERE age > 18 OR age IS NULL -- если хочешь включить "неизвестный возраст"


✅ Используй COALESCE:


SELECT COALESCE(discount, 0) FROM orders -- подставим 0, если скидка не указана


✅ Проверяй NULL через IS NULL / IS NOT NULL

✅ Для агрегаций учитывай поведение NULL:


AVG(column) -- пропустит NULL'ы, но COUNT(column) тоже не посчитает их!



Вывод:
NULL — не "ничего", а "неизвестно".
Пиши запросы так, как будто NULL всегда где-то прячется — и он не на твоей стороне.

Сохрани, чтобы не ловить грабли 💥

📲 Мы в MAX

#db

👉 @database_info

⚡️ Индексы в базах данных: как заставить запросы летать

Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.

Как это работает под капотом?
Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.

✅ Зачем нужны:

* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз.
* Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).

❌ Чем платим (минусы):

* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс.
* Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.

🛠 Чек-лист: индексировать или нет?

🟢 Обязательно индексируем:

1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY.
2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически.
3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).

🔴 НЕ индексируем:

1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс).
2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен).
3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.

💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.

📲 Мы в MAX

#db

👉 @database_info

🧱 Антипаттерн: Ненормализованная схема в SQL

Когда нужно «быстро запилить фичу», руки тянутся сделать одну таблицу, где и заказ, и клиент, и товары — всё в куче.

Пример:


CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_email TEXT,
product_1_name TEXT,
product_1_price NUMERIC,
product_2_name TEXT,
product_2_price NUMERIC
);


😰 Что пойдет не так:

– Дублирование данных — имя клиента повторяется в каждом заказе.
– Нет масштабируемости — максимум 2 продукта? А если будет 3?
– Трудности с запросами — попробуй посчитать топ-5 товаров. Удачи.
– Адские апдейты — изменить email клиента надо во всех заказах.

✅ Как правильно:

1. Нормализуй. Раздели данные на сущности: customers, orders, products, order_items.
2. Используй внешние ключи.
3. Не бойся JOIN'ов — они для этого и придуманы.

Пример нормализованной структуры:


-- Таблица клиентов
CREATE TABLE customers (
id SERIAL PRIMARY KEY,
name TEXT,
email TEXT
);

-- Таблица заказов
CREATE TABLE orders (
id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(id)
);

-- Таблица товаров
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name TEXT,
price NUMERIC
);

-- Связка товаров и заказов
CREATE TABLE order_items (
order_id INT REFERENCES orders(id),
product_id INT REFERENCES products(id),
quantity INT
);


📌 Да, нормализация требует чуть больше времени. Зато потом вы не утонете в хаосе.

Сохрани, чтобы не забыть — и не повторять чужих ошибок.

📲 Мы в MAX

#db

👉 @database_info

🎯 Мини-гайд: как НЕ спроектировать монстра вместо схемы БД

Когда проект только начинается, есть соблазн «не заморачиваться» и сделать одну большую таблицу на всё.
Спойлер: потом будет больно.

Вот как этого избежать 👇

1. Начинай с нормализации
– Смотри, какие поля повторяются.
– Разделяй по сущностям: клиент ≠ заказ ≠ товар.
– Нормальные формы — не академикам, а тебе на пользу.

2. Определи связи заранее
– Один ко многим? Многие ко многим?
– Используй FOREIGN KEY, чтобы база помогала тебе, а не мешала.

3. Не бойся JOIN-ов
– Да, их становится больше.
– Но это лучше, чем сотни NULL - ов и "status_1", "status_2" в одной колонке.

4. Планируй под рост
– Временные костыли становятся постоянными.
– Заложи масштабируемость: разнос сущностей, отдельные таблицы для логов, истории, связей.

5. Назначь ID-шки как бог велел
– PRIMARY KEY + автоинкремент или UUID.
– Не делай email или name ключом — это путь в баги.


🧠 Помни: хорошо спроектированная схема ускоряет разработку, а не тормозит её.
А переделывать схему сложнее, чем сделать нормально с самого начала.

📲 Мы в MAX

#db

👉 @database_info