"Давайте всё в одну таблицу." — сказал заказчик.Одна таблица, чтобы данными рулить,
Одна таблица, чтоб атрибуты всех найти,
Одна таблица, чтоб заказчику польстить...
И в дубликатах раствориться.
Через месяц: "Почему у Иванова три разных телефона и два дня рождения?"
Заказчик попросил отчёт по клиентам. Хочет видеть в одном месте: имя, телефон, заказы, суммы, статусы, даты. Всё.
"Сделайте одну табличку, я буду в ней работать."
Окей. Сделали. Одна таблица, 30 колонок. Заказчик доволен — всё перед глазами.
Через месяц приходит: "У клиента Иванов три строки с разными телефонами. Какой правильный?"
А правильный — все три. Потому что Иванов сделал три заказа. И в каждой строке его данные продублировались. Кто-то руками поправил телефон в одной строке, в другой — забил. Теперь непонятно, какой актуальный.
Ещё через неделю: "Посчитал общую сумму по клиенту — цифры не сходятся с бухгалтерией." Конечно не сходятся — у Иванова три заказа и две оплаты, в плоской таблице строки перемножились, и одна оплата посчиталась дважды.
Что пошло не такМы перепутали два уровня:
хранение и
представление.
🔸
Хранение — это как данные лежат в системе. Клиент — отдельно. Заказ — отдельно. Оплата — отдельно. Каждый факт записан один раз, в одном месте. Обновил телефон — обновился везде.
🔸
Представление — это как данные показываются пользователю. Тут — пожалуйста, одна таблица. Хоть 50 колонок. Но это витрина, не склад.
Проблема начинается, когда мы "хочу видеть одну таблицу" превращаем в "храним в одной таблице".
АналогияПредставь библиотеку. Книги стоят на полках — по автору, по жанру, по году. Это хранение. Всё на своих местах, легко найти, легко добавить новую.
А на столе у входа — подборка "Лучшее за март". Это представление. Те же книги, просто собраны удобно для читателя.
Никто не сваливает все книги в одну кучу на полу, потому что "так удобнее смотреть". Но с данными почему-то делают именно так.
Как надо былоЗаказчик говорит: "Хочу одну таблицу."
Правильный ответ: "Сделаем. Вы будете видеть всё в одном месте. Но под капотом данные будут храниться раздельно — чтобы телефон не дублировался и суммы не задваивались."
В базе — три таблицы:
клиенты,
заказы,
оплаты. Каждый факт один раз. Клиент связан с заказами, заказ — с оплатами. Цепочка, не каша.
Для заказчика — одно представление. Это может быть
VIEW (готовый запрос, который выглядит как таблица), отчёт или дашборд. Представление собирает данные из трёх таблиц в одну красивую картинку.
Заказчик видит то, что хотел. Данные не врут. Все довольны.
Что если "одна таблица" уже естьБывает, приходишь на проект — а там уже полгода живёт Excel на 40 колонок. Все в нём работают. Данные разъехались, но "мы привыкли".
Что делать:
1. Не ломай сразу — покажи проблему на их данных. Найди конкретного Иванова с тремя телефонами
2. Предложи миграцию поэтапно — сначала выносим справочник клиентов, потом заказы
3. Старую таблицу оставь как
VIEW на новую структуру — заказчик не заметит разницы, а данные перестанут врать
Выводы🔸 Слушай заказчика — но
в рамках представления, а не хранения. Он говорит, как хочет видеть. Не как хранить.
🔸 "Одна таблица" — это нормальный запрос на отображение. Ненормальный — на архитектуру.
🔸 Если данные дублируются — рано или поздно они разъедутся. Не "может быть", а
точно.
🔸 Разделяй витрину и склад. В IT так и говорят — "витрина данных". Покупатель видит красивую полку, а не весь склад с коробками.
🔸 Всё выше — про реляционные БД (PostgreSQL, MySQL). В колоночных БД (ClickHouse, Vertica) и хранилищах данных (DWH) широкие таблицы делают специально — для скорости запросов. Это осознанное решение, а не "заказчик попросил".
Мелочь, но половина проблем с данными — это не "система сломалась", а "изначально неправильно положили".
А у вас какой рекорд колонок в одной таблице? И удалось ли потом разделить — или так и живёте?
@analyst_exe 
