Что такое нормализация баз данных и зачем она нужна?

Да ты посмотри, какая история с этими базами данных! Сидишь ты такой, пишешь своё Node.js-приложение, и тут — ёпта — возникает вопрос: как данные-то хранить? Можно, конечно, всё в одну кучу свалить, как тот самый распиздяй, который все вещи в один чемодан пихает, а потом орет, что носки найти не может.

Вот смотри, есть у нас таблица user_orders. Выглядит вроде логично: заказ, пользователь, продукт — всё вместе, красота. Ан нет, чувак! Это же пиздец какой-то, если разобраться.

CREATE TABLE user_orders (
  order_id INT,
  user_name VARCHAR(100),  -- Один и тот же Вася будет в 100 заказах
  user_email VARCHAR(100), -- И его почта тоже
  product_name VARCHAR(100), -- И название товара
  -- ... и так далее
);

Представь: у Васи сменилась почта. И теперь тебе надо бегать по всем его заказам и в каждой строчке почту менять. Это ж ебать-колотить, какой геморрой! Это и есть «аномалия обновления». А если товар удалить из заказа — так и информация о нём нахуй пропадет. Вообще доверия к такой схеме — ноль ебать.

Нормализация — это когда умные дядьки придумали, как эту хуйню по полочкам разложить. Чтобы не было дублей, чтобы всё логично связано было. Как будто ты не в одну корзину всё кидаешь, а завел себе шкаф с отделениями: носки к носкам, майки к майкам.

Сначала приводим всё к первой нормальной форме (1NF). Это значит: никаких массивов в одной ячейке, всё атомарно. Каждая ячейка — одно значение. Не «яблоки, груши», а отдельно «яблоки» и отдельно «груши».

Потом вторая форма (2NF). Чтобы всё, что не относится к первичному ключу, зависело от него целиком, а не от части. Если ключ составной.

Ну и третья (3NF) — чтобы никакие поля не зависели друг от друга транзитивно. Типа «почта» зависит от «пользователя», а не от «номера заказа».

В итоге получается не одна жирная таблица, а несколько аккуратных:

CREATE TABLE users (          -- Отдельно пользователи
  user_id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL
);

CREATE TABLE products (       -- Отдельно продукты
  product_id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL
);

CREATE TABLE orders (         -- Отдельно заказы
  order_id SERIAL PRIMARY KEY,
  user_id INT REFERENCES users(user_id) -- Ссылка на юзера
);

CREATE TABLE order_items (    -- И таблица-связка: что в каком заказе
  order_id INT REFERENCES orders(order_id),
  product_id INT REFERENCES products(product_id),
  quantity INT NOT NULL
);

А в Node.js с Sequelize это выглядит вообще красиво:

const User = sequelize.define('User', { name: DataTypes.STRING });
const Product = sequelize.define('Product', { name: DataTypes.STRING });
const Order = sequelize.define('Order', {});

// Настраиваем связи
User.hasMany(Order);
Order.belongsTo(User);
Order.belongsToMany(Product, { through: 'OrderItem' });
Product.belongsToMany(Order, { through: 'OrderItem' });

// И потом запрос такой, чтоб всё достать:
const userOrders = await User.findOne({
  where: { id: 1 },
  include: [{ model: Order, include: [Product] }]
});

В чём, блядь, профит?

1. Дублей нет. Почта Васи хранится в одном месте. Поменял — и нахуй всем достаточно.
2. Целостность. Удалил заказ — товары остались в каталоге. Не надо выёбываться с восстановлением.
3. Производительность. На маленьких полях индексы строятся быстрее, JOIN'ы лучше работают.
4. Гибкость. Захотел добавить категории товаров — создал таблицу categories и ссылку в products. И не надо переделывать всю хуйню.

Но! Не всё так однозначно, чувак. Иногда нормализация приводит к тому, что для простого отчёта тебе надо сделать 15 JOIN'ов. База начинает ебашить диск как сумасшедшая. Вот тогда иногда денормализацию применяют — сознательно дублируют данные, чтобы читалось быстрее. Например, для дашбордов или аналитики. Но это уже осознанный компромисс, а не потому что ты ленивая жопа.

Короче, нормализуй, пока не станет больно. А как станет больно — думай, где можно слегка считерить. Главное — понимать, зачем ты это делаешь, а не просто следовать правилам, как мартышлюшка.