Ненормализованная схема в SQL
🧱 Антипаттерн: Ненормализованная схема в 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’ов — они для этого и придуманы.
📌 Да, нормализация требует чуть больше времени. Зато потом вы не утонете в хаосе.
Сохрани, чтобы не забыть — и не повторять чужих ошибок.
· 25.01
Добрый день! А по вашему опыту, как чаще хранят паспортные данные - в нормализованном или ненормализованном виде? Речь про: серию, номер, ФИО, пол, дату/ место рождения, дату выдачи, кем выдан, код подразделения
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён