Антипаттерны проектирования БД: как нормализовать таблицу и потерять данные, не удалив ни одного значения
A team at Modus that builds ETL and BI solutions says it regularly sees the insides of other companies' databases — during implementations, technical consulting, case reviews and migrations. They describe encountering the same mistake so often, and hidden so cleverly, that it deserves its own breakdown and the status of a recognized antipattern. The article opens a series devoted to database design antipatterns. Judging by the title, the first installment covers how normalizing a table can cause data loss even when no individual value has been deleted.
Мы в Modus делаем ETL и BI, и видим чужие базы данных изнутри: на каждом внедрении, на техническом консультировании, на разборах кейсов и на каждой миграции. Навидались всякого. Но одна ошибка попадается так часто и прячется так ловко, что заслуживает отдельного разбора… и почётного звания антипаттерна. Начинаем цикл статей, посвящённых антипаттернам проектирования баз данных именно с неё. Представьте: миграция позади. Заказы, товары и склады на месте. Число строк сошлось, проверки горят зелёным, можно закрывать задачу. Но только никто — ни аналитик, ни разработчик, ни самый хитрый SQL-запрос, — уже не скажет, с какого склада уехал конкретный товар. Не удалено ни одного значения. А данные протеряны. Это сбой миграции? Ошибка в запросе? Нет! Это ошибка проектирования , которая очень похожа на безобидную нормализацию. Давайте разберём, откуда она берётся, почему стандартные проверки её не видят и почему исправить её задним числом уже нельзя. Не «дорого и сложно», а вообще невозможно математически. А в конце — задачка для тех, кто (как и мы когда-то) уверен, что опыт и знания надёжно ограждают его от таких новичковых ошибок. Читать далее