Вы когда-либо встречались с запросом, который не мог выполнить SQL Server, потому что он сослался на слишком много таблиц?
Я полагаю из вашего примера статического массива, что вам нужен прямоугольный массив, а не зубчатый. Вы можете использовать следующее:
int *ary = new int[sizeX * sizeY];
Затем вы можете получить доступ к элементам как:
ary[y*sizeX + x]
Не забудьте использовать delete [] на ary.
7 ответов
Для SQL Server 2005 я рекомендовал бы использовать табличные переменные и частично создать данные, когда Вы идете.
, Чтобы сделать это, создайте табличную переменную, которая представляет Ваш конечный результат, устанавливает Вас, хотят отправить пользователю.
Затем находят Вашу первичную таблицу (скажите, что таблица заказов в Вашем примере выше), и вытягивают те данные, плюс немного дополнительных данных, которые являются, только говорят что одно соединение далеко (имя клиента, название продукта). Можно сделать ВЫБОР В поместить это прямо в табличную переменную.
Оттуда, выполните итерации через таблицу и для каждой строки, сделайте набор маленьких Запросов Select, который получает все дополнительные данные, в которых Вы нуждаетесь для своего набора результатов. Вставьте их в каждый столбец, когда Вы идете.
Однажды завершенный, можно затем сделать простой ВЫБОР * от табличной переменной и возвратить этот набор результатов пользователю.
у меня нет твердых чисел для этого, но было три отличных экземпляра, что я продолжил работать до настоящего времени, где выполнение этих меньших запросов на самом деле работало быстрее, чем выполнение одного крупного запроса Select с набором соединений.
Я никогда не сталкивался с этим видом ситуации, и быть честным идея сослаться> 256 таблиц в филсе запроса меня со смертным страхом.
Ваш первый вопрос должен, вероятно, "Почему так многие?", тесно сопровождаемый, "какие биты информации делают меня НЕ потребность?" Я волновался бы, что объем данных, возвращаемый из такого запроса, начнет влиять на производительность приложения вполне сильно, также.
@chopeen Вы могли изменить способ, которым Вы вычисляете эти статистические данные и вместо этого сохраняете отдельную таблицу всей статистики на продукт.. когда заказ будет размещен, цикл через продукты, и обновите соответствующие записи в таблице статистики. Это сместилось бы, большое вычисление загружается к странице контроля вместо того, чтобы выполнить все в одном огромном запросе при выполнении отчета. Конечно, существует некоторая статистика, которая не собирается работать также этот путь, например, отслеживает следующие покупки клиентов после покупки конкретного продукта.
Это произошло бы все время при написании Отчетов Reporting Services для установок CRM Динамики, работающих на SQL Server 2000. CRM имеет приятно нормализованную схему данных, которая приводит к большому количеству соединений. Существуют на самом деле текущие исправления вокруг этого, будет предел от 256 до целых 260: http://support.microsoft.com/kb/818406 (мы всегда думали это большая шутка со стороны команды SQL Server).
решение, как Dillie-O ссылающийся к, состоит в том, чтобы определить соответствующий, "добавляет" (предпочтительно, которые используются многократно), и факторизуйте их в поддающиеся соблазну переменные, которые Вы затем используете в своих основных соединениях. Это - главный PIA и часто уничтожает производительность. Я сожалею о Вас.
@Kevin, любовь, которые кладут для первого удара - говорит все это :-).
Я хотел бы видеть, что запрос, но я предполагаю, что это - некоторая проблема со своего рода итератором, и в то время как я не могу думать ни о каких ситуациях, где ее возможное, я держал пари, что это от плохого while/case/cursor или тонны плохо реализованных представлений.
Отправьте запрос :D
Также я чувствую, что одна из возможных проблем могла иметь тонну (читайте 200 +) имени/таблиц значений, которое могло сжатый в единственную справочную таблицу.
У меня была такая же проблема ... мой блок разработки запускает SQL Server 2008 (представление работало хорошо), но на производстве (с SQL Server 2005) представление не было. В итоге я создал представления, чтобы избежать этого ограничения, используя новые представления как часть запроса в представлении, в котором возникла ошибка.
Это глупо, учитывая то же логическое исполнение ...