Предполагая, что у меня есть две таблицы: источник и статья, и я хочу прочитать статью с конкретными деталями ее источника, я могу либо использовать соединение для двух таблиц; или (2) дублируйте данные в записи статьи (что сделает блок данных более крупным, но запрос будет очень простым). , который был бы более эффективным?MySQL: дублирование данных против присоединения
Зависит, вам не нужно дублировать данные в своей базе данных? Затем, когда вам нужно что-то обновить, вам придется обновлять его в нескольких местах. Иногда его хорошо иметь небольшие дубликаты данных, но чтобы избежать объединения всех вместе, возможно, негативно повлияет на вас.
Зависит от данных. Допустим, у вас огромная таблица статей и небольшая таблица авторов. Если вы хотите сделать много запросов, которые получат некоторые данные статьи и имя автора (это в таблице статей по умолчанию), тогда у вас будет простой поиск первичного ключа для каждой строки «автора», а небольшой таблица, вероятно, поместилась бы в памяти, поэтому не будет большого повышения производительности, включая имя автора в таблице статей. Кроме того, этот denormalization также сделает таблицу «статей» немного больше (имя каждого автора будет дублироваться много раз), поэтому он будет использовать больше вашего кеша.
С другой стороны, если вы хотите запросить количество статей для каждого автора, получение этих данных из двух таблиц будет означать объединение множества строк каждый раз. Но если вы включили бы это число в таблицу «авторы», получение его означало бы только один поиск и прирост для каждой добавленной статьи. Поэтому, если вас интересуют такие результаты, денормализация может иметь смысл.
который был бы более эффективным?
Проще говоря (возможно, слишком просто): вы торгуете памятью для циклов процессора, что может привести к ухудшению кеширования и снижению производительности.
Единственный способ правильно ответить на ваш вопрос - принять вашу среду и измерить производительность. Не забудьте включить «правильно» индексированные таблицы. Создайте реалистичную нагрузку на базу данных - например, убедитесь, что вы не попадаете в кеш для одних и тех же строк снова и снова.
Спросите себя заранее, если от того, какой прирост производительности (1%, 10%, 100%), стоит начать денормализацию.
Это дизайнерское решение, которое означает, что без всех деталей вашего анализа (цели, ограничения, требования пользователей и т. Д.), Но несколько правил, которыми я пользуюсь;
1/Соединение между двумя столами, как правило, не очень дорогое, и это простой случай для настройки (например, вы говорите, что обновление будет мало, и я предполагаю, что не имеет большого количества вставки/удаления, и в основном выбирает поэтому, это вероятно чтобы ускорить индексацию)
2 При проектировании схемы сначала нормализуйте ее до наивысшей степени возможной/разумной, а затем, когда сценарии реального мира доказывают, что это стоит, денормализовать. (И, как правило, решение нормализовать, а затем денормализовать конкретные элементы работает достаточно хорошо, неспособность нормализовать, как правило, не дает хорошего результата.
3/В течение периода времени нормализация оплачивается сама собой (в последующие годы, когда вы пытаетесь сделать некоторые изменения в системе, хорошо спроектированный фундамент по-настоящему приветствуется и оценивается)
4/Denormalising, как мне кажется, лучше всего подходит для ситуаций отчетности, в которых будут использоваться специальные запросы.Или, другими словами, основная причина, по которой я вижу денормализацию, облегчает жизнь писателям отчетов, у которых высокий уровень запроса-записи/использования
дублирующие данные могут принести вам больше производительности. Заметьте, я написал, потому что у вас будут проблемы с кешированием. С другой стороны, при дублировании данных вы затрудняете работу с вашей системой (BTW, вы нарушаете нормальную форму БД). Если цена, которую вы должны заплатить, - это всего лишь одно соединение таблицы, а затем просто платите. Убедитесь, что у вас есть indexex на столбцах, которые вы присоединяете, а затем цена совсем не будет такой дорогостоящей.
Нижняя строка: никогда не дублируйте данные, если это не критично.
Если чтение является приоритетом, вы можете использовать Materialized Views. Поскольку MySQL не поддерживает их (я думаю), вы можете simulate them.
Это решение позволяет сохранить исходную базу данных нормализованной, но вы получаете производительность, задаваемую простыми запросами от MV.
Для аргументации быстрое чтение является моим главным приоритетом, поэтому я готов рискнуть более сложными операциями записи. (не говоря уже о том, что большинство моих данных не допускают изменения после написания) – Oded