«Давайте всё в одну таблицу», — сказал заказчик. Через месяц: «почему у Иванова три разных телефона и два дня рождения?». Это классическая ловушка: запрос на то, как удобно смотреть, превратили в решение о том, как хранить. А это два разных уровня.

Как ломается «одна табличка»

Заказчик попросил отчёт по клиентам: имя, телефон, заказы, суммы, статусы, даты — всё в одном месте. «Сделайте одну табличку, я буду в ней работать». Сделали: одна таблица, 30 колонок, заказчик доволен.

Через месяц: «у клиента Иванов три строки с разными телефонами, какой правильный?». А правильный — все три: Иванов сделал три заказа, и в каждой строке его данные продублировались. Кто-то поправил телефон в одной строке, в другой забыл — теперь непонятно, какой актуальный.

Ещё через неделю: «общая сумма по клиенту не сходится с бухгалтерией». Конечно: у Иванова три заказа и две оплаты, в плоской таблице строки перемножились, и одна оплата посчиталась дважды.

Что пошло не так: хранение ≠ представление

Мы перепутали два уровня.

Хранение — как данные лежат в системе. Клиент отдельно, заказ отдельно, оплата отдельно. Каждый факт записан один раз, в одном месте. Обновил телефон — обновился везде.

Представление — как данные показываются пользователю. Тут пожалуйста: одна таблица, хоть 50 колонок. Но это витрина, а не склад.

Представь библиотеку. Книги стоят на полках по автору и году — это хранение. На столе у входа подборка «лучшее за март» — это представление. Никто не сваливает все книги в кучу на полу, потому что «так удобнее смотреть». С данными почему-то делают именно так.

Как надо было

Заказчик говорит «хочу одну таблицу». Правильный ответ: «сделаем, вы будете видеть всё в одном месте, но под капотом данные будут храниться раздельно — чтобы телефон не дублировался и суммы не задваивались».

В базе — три таблицы: клиенты, заказы, оплаты. Каждый факт один раз, клиент связан с заказами, заказ с оплатами. Цепочка, не каша. Для заказчика — одно представление: VIEW (готовый запрос, который выглядит как таблица), отчёт или дашборд, который собирает данные из трёх таблиц в одну картинку. Заказчик видит то, что хотел, данные не врут.

Что делать, если «одна таблица» уже есть

Бывает, приходишь на проект — а там полгода живёт Excel на 40 колонок, все в нём работают, данные разъехались, но «мы привыкли». Тогда:

  1. Не ломай сразу — покажи проблему на их данных. Найди конкретного Иванова с тремя телефонами.
  2. Предложи миграцию поэтапно: сначала выносим справочник клиентов, потом заказы.
  3. Старую таблицу оставь как VIEW на новую структуру — заказчик не заметит разницы, а данные перестанут врать.

Выводы

  • Слушай заказчика — но в рамках представления, а не хранения. Он говорит, как хочет видеть, а не как хранить.
  • «Одна таблица» — нормальный запрос на отображение и ненормальный на архитектуру.
  • Если данные дублируются — рано или поздно они разъедутся. Не «может быть», а точно.
  • Исключение: в колоночных БД (ClickHouse, Vertica) и хранилищах (DWH) широкие таблицы делают специально — для скорости запросов. Это осознанное решение, а не «заказчик попросил».

Мелочь, но половина проблем с данными — это не «система сломалась», а «изначально неправильно положили».