MySQL: дублирование данных и объединение - PullRequest
2 голосов
/ 09 мая 2009

Предполагая, что у меня есть две таблицы: источник и статья, и я хочу прочитать статью с конкретными подробностями ее источника, я могу либо (1) использовать объединение для двух таблиц; или же (2) дублировать детали к записи статьи (что увеличит размер блока данных, но запрос будет очень простым). что будет более эффективным?

Ответы [ 6 ]

3 голосов
/ 09 мая 2009

что будет более эффективным?

Проще говоря (возможно, слишком просто): вы торгуете памятью для циклов ЦП, что может привести к ухудшению кеширования и снижению производительности

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

Спросите себя заранее, стоит ли начинать денормализацию с какого прироста производительности (1%, 10%, 100%).

3 голосов
/ 09 мая 2009

Зависит от данных. Допустим, у вас есть огромная таблица статей и небольшая таблица авторов. Если вы хотите выполнить много запросов, которые бы получили данные статьи и имя автора (который по умолчанию находится в таблице статей), то у вас был бы простой поиск первичного ключа для каждой строки «автора» и небольшой Таблица, вероятно, уместилась бы в памяти, поэтому не будет существенного увеличения производительности от включения имени автора в таблицу статей. Кроме того, эта денормализация также сделает таблицу «статей» немного больше (имя каждого автора будет дублироваться много раз), поэтому он будет использовать больше вашего кеша.

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

2 голосов
/ 09 мая 2009

Это проектное решение, которое означает, что без всех деталей вашего анализа (цели, ограничения, требования пользователя и т. Д.), Кроме нескольких практических правил, которые я использую;

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

2 / При разработке схемы сначала нормализуйте ее в максимально возможной степени / разумно, а затем, когда сценарии реального мира доказывают ее целесообразность, денормализуйте. (И, как правило, решение нормализовать, а затем денормализовать определенные элементы работает довольно хорошо, отказ от нормализации обычно не дает хорошего результата.

3 / В течение определенного периода времени нормализация окупается (в последующие годы, когда вы пытаетесь внести некоторые изменения в систему, хорошо продуманная основа действительно приветствуется и приветствуется)

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

2 голосов
/ 09 мая 2009

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

1 голос
/ 09 мая 2009

Если производительность чтения является приоритетом, вы можете использовать Материализованные представления . Поскольку MySQL их не поддерживает (я думаю), вы можете имитировать их .

Это решение позволяет нормализовать исходную базу данных, но при этом вы получаете производительность, полученную от простых запросов от MV.

0 голосов
/ 09 мая 2009

дублирование данных может повысить производительность. Заметьте, я мог написать, потому что у вас будут проблемы с кэшированием. С другой стороны, дублируя данные, вы усложняете обслуживание вашей системы (кстати, вы нарушаете нормальную форму БД). Если цена, которую вы должны заплатить, - это только одно присоединение к столу, просто заплатите. Убедитесь, что у вас есть indexex для столбцов, к которым вы присоединяетесь, и тогда цена вовсе не будет такой дорогой.

Итог: никогда не дублируйте данные, если это не критично.

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