MySQL - Должен ли я денормализовать?

Question

Обзор (Извините, что расплывчато - думаю, если бы я попал в подробности, это только усложнило бы вещи)

У меня есть три таблицы, в первой таблице содержится идентификатор, во второй таблице - свой идентификатор, а в таблице один, а в таблице три - свой идентификатор и идентификатор второй таблицы.

Я потратил много времени на размышления, и я думаю, что было бы более эффективно, если бы в таблице 3 также содержался идентификатор связанных таблиц.

-Это будет означать, что мне не придется объединять три таблицы, я могу просто запросить таблицу три (для запроса, который будет использоваться очень часто)

-Это позволит мне проще реализовать систему бронирования, блокируя только те строки в таблице три, которые содержат определенный идентификатор из таблицы один.

Для тех, кто хочет узнать больше о макете базы данных, есть дополнительная информация здесь

Вопрос

Каковы недостатки для нормализации? Я видел некоторых людей, которые полностью против этого, и других, которые верят в правильную ситуацию, это полезный инструмент. Идентификаторы никогда не изменятся, поэтому я не вижу никаких недостатков, кроме необходимости вставлять одни и те же данные дважды, и, следовательно, дополнительное пространство, которое они будут использовать (который, как и просто идентификаторы, наверняка будет незначительным).

Answer 1

Мой совет - следовать этому общему правилу: нормализовать по умолчанию, затем денормализовать, если и когда вы обнаружите проблему с производительностью, которую она решит.

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

Answer 2

Как один (Таблица 1) до много (Таблица 2), с другим один (таблица 2) до много (Таблица 3) Я бы сохранил ту же структуру, что и их, кажется, там 3 слоя.

, например

• Таблица 1
  • Таблица 2
    • Таблица 3

Кроме того, многое будет зависеть от того, какие дополнительные поля вы храните в этих таблицах.

Answer 3

Каждое правило может быть нарушено, если для этого есть веская причина.

В вашем случае мне интересно, что содержат три таблицы. Таблица 3 действительно описывает Таблицу 2 или она описывает непосредственно Таблицу 1?

Недостаток наличия в таблице три self-id, table-two-id и table-one-id в этом случае заключается в том, что это может привести к несогласованности - что если у вас есть table-one-id 1 в таблице два а table-one-id 15 в таблице три по ошибке?

Это зависит от данных и отношения сущности ваших данных. Для меня было бы важнее не иметь противоречий и иметь немного больше времени при выборе ...

РЕДАКТИРОВАТЬ: После прочтения ваших таблиц я бы предложил добавить идентификатор таблицы один к таблице три (области), потому что идентификатор таблицы один не меняется в конце концов и по этой причине его относительно сохранить за несогласованность.

Answer 4

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

Это уже спрашивали несколько раз. Смотри здесь

Answer 5

Схемы, содержащие не полностью нормализованные таблицы, страдают от так называемой «вредной избыточности». Вредная избыточность может привести к хранению одного и того же факта в более чем одном месте или к отсутствию места для хранения факта, который необходимо сохранить. Эти проблемы известны как «вставка аномалий», «обновление аномалий» или «удаление аномалий».

Короче говоря, если вы храните факт более чем в одном месте, то рано или поздно вы собираетесь хранить взаимно противоречивые факты в двух местах, и ваша база данных начнет давать противоречивые ответы, в зависимости от какую версию фактов нашел запрос.

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

Если вы супер-программист и никогда не ошибаетесь, вам не нужно беспокоиться об этом. Я никогда не встречал такого программиста, хотя встречал много людей, которые думают, что никогда не ошибаются.

Я бы воздержался от "денормализации" как практики. Это как "отъехать из Чикаго". Вы все еще не знаете, куда идете. Однако бывают случаи, когда правила нормализации должны игнорироваться, как отметили другие. Если вы разрабатываете схему типа «звезда» (или схему «снежинка»), вам придется игнорировать некоторые правила нормализации, чтобы получить лучшую звезду (или снежинку).

Answer 6

Нормализация против эффективности - это обычно компромисс, хотя нормализация, как правило, хорошая вещь, это не серебряная пуля. Если у вас есть четкая причина (как вам кажется), денормализация вполне приемлема.