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

Ответ 1

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

Ответ 2

Два вопроса:

• Это работает?
• Вы можете объяснить это?

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

Это совсем не необычно. С такой системой, как Siebel, обычно видно, что количество объединений в двойных цифрах.

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

Из любопытства, является ли это DB2? Только что я заметил:)

Ответ 12

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

Ответ 13

- это 7 внутренних объединений в одной таблице, 7 внутренних объединений в разных таблицах или 7 вложенных внутренних соединений?

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

caveat: если это 7 вложенных внутренних объединений в одной таблице, у вас, вероятно, есть плохо структурированная таблица; -)

Ответ 14

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