Соединения SQL по сравнению с единственной таблицей: различие в производительности?

Michael Jackson (не , что один) заметно полагавший сказать ,

• Первое Правило Оптимизации Программы: не делайте этого.
• Второе Правило Оптимизации Программы †“Для экспертов только: еще не делайте этого.

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

ВЫБОРЫ Мультитаблицы почти всегда необходимы с нормализованной моделью данных; как это часто бывает с этим видом вопроса, "корректный" ответ на "денормализовывает?" вопрос зависит от нескольких факторов.

платформа DBMS.

относительная производительность мульти - по сравнению с запросами единственной таблицы под влиянием платформы, на которой живет Ваше приложение: уровень изощренности оптимизаторов запросов может варьироваться. MySQL, например, по моему опыту, поразительно быстр на запросах единственной таблицы, но не оптимизирует запросы с несколькими соединениями так хорошо. Это не реальная проблема с меньшими таблицами (меньше, чем 10K строки, скажите), но действительно повреждает с большим (10M +).

Объем данных

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

(De-) нормализация

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

Требования/Ограничения

, Какие требования к производительности Вы пытаетесь встретить? У Вас есть починенные аппаратные средства или бюджет? Иногда повышение производительности может быть наиболее легко - и даже наиболее дешево - достигнуто модернизацией оборудования. Какие объемы сделок Вы ожидаете? Система учета малого бизнеса имеет совсем другой профиль к, скажем, Twitter.

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

Мы оставляем оптимизацию запросов до базы данных по тем же причинам, мы оставляем оптимизацию кода до компилятора.

самые современные RDBMSes довольно хороши в этом отношении в эти дни.

, Прежде чем Вы будете думать, что денормализация 'в порядке' в некоторых случаях, рассмотрите это: обычно Вы не интересуетесь каждым атрибутом. Поэтому загрузка ненужных данных от диска неэффективна (обычно наименее эффективный компонент базы данных). Это может быть намного хуже, если у Вас есть денормализованный дизайн с большим количеством избыточных данных подряд. Еще хуже снова, если необходимо тогда обновить все эти избыточные данные. Может быть намного более эффективно загрузить некоторые узкие таблицы, содержащие только столбцы интереса и присоединиться к ним. Снова, это зависит от базы данных, таким образом, не представляя у Вас нет подсказки.

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

Существует стоимость для разлагающихся таблиц ради нормализации. Существует компонент производительности к той стоимости. Стоимость производительности разлагающихся таблиц и присоединяющихся данных в запросах может быть поддержана на низком уровне: использование хорошего DBMS; разработка права таблиц; разработка индексного права; разрешение оптимизатору сделать его задание; и настройка DBMS определенные функции физического дизайна.

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

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

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

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

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

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

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

Различие в производительности?

Различие в исправности.