Семь внутренних объединений в запросе слишком много?

Question

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

Answer 1

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

Answer 2

Два вопроса:

1. Это работает?
2. Ты можешь это объяснить?

Если так, то семь - это хорошо. Если вы не можете объяснить запрос, то семь - это слишком много.

Answer 3

Это нормально, если ваша схема находится в 5-й нормальной форме :)

Answer 4

В зависимости от того, что вы пытаетесь выполнить, большое количество объединений в запросе не примечательно.

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

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

Answer 5

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

Answer 6

Это совсем не необычно. В такой системе, как Siebel, число соединений обычно отображается в двойных числах.

Answer 7

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

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

Answer 8

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

Оптимизатор запросов SQL Server оценивает как минимум одну строку, выходящую из оператора поиска. Это сделано для того, чтобы избежать случая, когда выбирается очень дорогое поддерево из-за недооценки мощности. Если предполагается, что поддерево возвращает ноль строк, многие планы стоят примерно одинаково, и в результате могут быть ошибки при выборе плана. Итак, вы заметите, что оценка «высокая» для этого случая, и могут возникнуть некоторые ошибки. Вы также можете заметить, что мы оцениваем 20 выполнений этой ветви вместо фактических 10. Однако, учитывая количество объединений, которые были оценены до этого оператора, отключение с коэффициентом 2 (10 строк) не считается очень плохо. ( Ошибки могут увеличиваться в геометрической прогрессии с числом соединений ).

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

Answer 9

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

если это работает для вас, тогда я думаю, это нормально: D

Answer 10

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