Лучше ли хранить избыточную информацию или объединять таблицы, когда это необходимо в MySQL? - PullRequest
7 голосов
/ 13 июля 2010

У меня есть интернет-магазин, где пользователи могут иметь небольшие магазины со своими продуктами. У каждого из этих продуктов могут быть вопросы, связанные с ним, и владелец магазина имеет возможность ответить на эти вопросы. Эта информация хранится в 3 таблицах: таблица «Вопросы» (QuestionID, ProductID, ...), таблица «Products» (ProductID, ShopID, ...) и «Магазин» (ShopID, OwnerID, ...) Таблица.

Лучше ли иметь ShopID в таблице «Вопросы» (чтобы владелец магазина мог просмотреть все его вопросы) или присоединиться к этим трем таблицам, чтобы получить Вопросы, соответствующие определенному Магазину?

Ответы [ 5 ]

10 голосов
/ 13 июля 2010

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

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

2 голосов
/ 13 июля 2010

С точки зрения дизайна, сохранение избыточных данных не является необходимым.В вашем случае это может быть.Попробуйте выполнить несколько тестов, и если время запроса увеличится из-за этой избыточности, вам следует приступить к денормализации.

2 голосов
/ 13 июля 2010

Обычно лучше избегать избыточной информации.Похоже, что это должно быть довольно дешевым соединением для выполнения соответствующих индексов, и я не буду денормализовать таким образом, если только в планах запросов не увижу, что JOIN вызывает проблемы (возможно, из-за количества записей в таблицах)1001 *

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

1 голос
/ 13 июля 2010

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

Кстати: вы должны использовать отношение m: n между продуктами и магазинами и удалить ShopID для продуктов. Таким образом, вы можете иметь один и тот же продукт в разных магазинах и , а также одинаковые вопросы для продукта.

С уважением, Ларс

1 голос
/ 13 июля 2010

Вы должны иметь много-много взаимосвязей между вопросами и продуктами:

questions_ref (вопрос_ид, код вопроса, вопрос)

product_questions (pquestion_id, question_id_fk, product_id_fk)

продукты (идентификатор продукта, имя продукта и т. Д.)

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

shop_products (sproduct_id, product_id_fk, shop_id_fk, sproduct_price, other_shop_specific_param)

магазины (shop_id, owner_id_fk, shop_name и т. Д.)

...