mySQL - следует ли денормализовать?

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

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

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

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

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

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

Вопрос

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


mysql database database-design denormalization
person Mark    schedule 13.11.2009    source источник
comment
я должен ?: определенно нет; денормализация в основном используется, когда возникает серьезная немасштабируемая проблема с производительностью. Если у вас этого нет (и вы не можете подтвердить это утверждение достоверными данными), вам не следует этого делать, поскольку преимущества будут незначительными. См. stackoverflow.com/questions/561900/   -  person Piskvor left the building    schedule 13.11.2009

Ответы (6)


arrow_upward
6
arrow_downward

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

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

person Ben James    schedule 13.11.2009

arrow_upward
1
arrow_downward

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

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

person Chris Klepeis    schedule 13.11.2009

arrow_upward
1
arrow_downward

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

e.g.

  • Table 1
    • Table 2
      • Table 3

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

person kevchadders    schedule 13.11.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

person Pesse    schedule 13.11.2009

arrow_upward
0
arrow_downward

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

person chills42    schedule 13.11.2009

arrow_upward
0
arrow_downward

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

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

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

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

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

person Walter Mitty    schedule 13.11.2009