Что хотят услышать интервьюеры:

Нужно показать, что плохая нормализация — это хранение одних и тех же данных в нескольких местах или смешивание разных сущностей в одной таблице. Такой дизайн приводит к дублированию, аномалиям обновления и рискам несогласованности данных. Хороший ответ обычно включает конкретный пример и объяснение, почему это плохо.

Определение:

Плохая нормализация — это структура базы, в которой данные избыточно дублируются или не разделены по смысловым сущностям. Из-за этого обновление одной информации требует менять несколько строк или таблиц, и при ошибке данные начинают расходиться.

Пример использования:

Допустим, в таблице заказов хранятся одновременно данные о заказе, клиенте и товаре:

orders = [
    {
        "order_id": 1,
        "customer_name": "Иван Петров",
        "customer_phone": "+7-900-111-22-33",
        "product_name": "Ноутбук",
        "product_price": 120000
    },
    {
        "order_id": 2,
        "customer_name": "Иван Петров",
        "customer_phone": "+7-900-111-22-33",
        "product_name": "Мышь",
        "product_price": 2000
    }
]

Здесь данные клиента повторяются в каждой записи заказа. Если номер телефона изменится, его нужно исправить во всех строках. Если обновить только одну — база станет противоречивой.

Пояснение кода:

Код нужен, чтобы показать проблему наглядно.

В списке orders одна и та же сущность клиента продублирована в двух заказах.
Это означает, что информация о клиенте хранится не отдельно, а вместе с каждым заказом.
При изменении телефона клиента нужно пройти по всем записям и обновить их.
Если этого не сделать, в базе появятся разные значения для одного и того же клиента.
Более нормальный подход — хранить клиента отдельно в таблице customers, а в orders оставить только customer_id.

Ключевые моменты:

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

Можешь привести пример ситуации, когда база данных находится в плохой нормализации?