Вы когда-нибудь сталкивались с запросом, который SQL Server не мог выполнить, поскольку он ссылался на слишком много таблиц?

Вы когда-нибудь видели сообщения об ошибках?

- SQL Server 2000

Не удалось выделить вспомогательную таблицу для просмотра или разрешения функции.
Максимальное количество таблиц в запросе (256) было превышено.

- SQL Server 2005

Слишком много имен таблиц в запросе. Максимально допустимое значение - 256.

Если да, что вы сделали?

Сдается? Убедился ли клиент в упрощении своих требований? Денормализовать базу данных?

@(все хотят, чтобы я опубликовал запрос):

Я не уверен, могу ли я вставить 70 килобайт кода в окно редактирования ответов.
Даже если я могу это сделать, это не поможет, так как 70 килобайт кода будет ссылаться на 20 или 30 просмотров, которые мне также нужно будет публиковать, так как иначе код будет бессмысленным.

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

Ответ 1

Для SQL Server 2005 я бы рекомендовал использовать переменные таблицы и частично строить данные по мере их поступления.

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

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

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

После завершения вы можете сделать простой SELECT * из вашей таблицы и вернуть этот результат пользователю.

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

Ответ 2

Я никогда не сталкивался с такой ситуацией, и, честно говоря, идея ссылки нa > 256 таблиц в запросе ставит меня в смертельный страх.

Ваш первый вопрос должен, вероятно, "Почему так много?", за которым следует "какие части информации мне НЕ нужны?" Я был бы обеспокоен тем, что количество данных, возвращаемых из такого запроса, также сильно повлияет на производительность приложения.

Ответ 3

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

Ответ 4

Это будет происходить все время при написании отчетов служб отчетов для установок Dynamics CRM, работающих на SQL Server 2000. У CRM есть хорошо нормализованная схема данных, которая приводит к большому количеству объединений. На самом деле есть исправление вокруг, которое превысит лимит от 256 до колоссального 260: http://support.microsoft.com/kb/818406 (мы всегда считали это большой шуткой на часть команды SQL Server).

Решение, как и Dillie-O, состоит в том, чтобы идентифицировать соответствующие "под-соединения" (предпочтительно те, которые используются несколько раз), и разложить их на переменные temp-table, которые затем используются в ваших основных объединениях. Это крупный PIA и часто убивает производительность. Прошу прощения за вас.

@Кевин, любите этот тройник - говорит все: -).

Ответ 5

Я бы хотел увидеть этот запрос, но я представляю, что это проблема с каким-то итератором, и хотя я не могу придумать никаких ситуаций, где это возможно, я готов поспорить на это из-за плохого /case/cursor или тонна слабо реализованных представлений.

Ответ 6

Отправьте запрос: D

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

Ответ 7

У меня была такая же проблема... в моей коробке разработки работает SQL Server 2008 (представление отлично работало), но в процессе производства (с SQL Server 2005) этого представления не было. Я закончил создание представлений, чтобы избежать этого ограничения, используя новые представления как часть запроса в представлении, которое запустило ошибку.

Вид глупых, рассматривающих логическое выполнение, тот же...

Ответ 8

Имела ту же проблему в SQL Server 2005 (работала в 2008 году), когда я хотел создать представление. Я решил проблему, создав хранимую процедуру вместо представления.