2013-12-15 5 views
1

НАСТРОЙКА:Возврат частичные результаты из SQL

  • asp.net MVC3
  • C#
  • SQL Server 2008 R2
  • jQgrid

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

Если условия правильные, часто приходится ждать SQL или получить ошибку MAXJSONLENGTH при визуализации результатов.

Я бы предпочел, чтобы: SQL все результаты возвращаются в партии из 500 записей, C# и серию и пропускают партию, а jQgrid выполняет загрузку результатов по их мере появления. Это заставит его чувствовать себя более отзывчивым и избежать ошибок таймаута и максимальной длины.

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

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

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

Что вы посоветуете? Или я передумал это? (Я не прошу вас закодировать его, хотя не жаловался бы, если бы у вас был пример. Мне просто нужны новые идеи в том, как решить эту проблему).

ответ

0

Из вашего вопроса, который я вывел, есть некоторые запросы, которые возвращают значительное количество строк, что приводит к ошибке max json или ошибке таймаута.

Я предлагаю вам использовать разбивку на страницы и сделать запрос на возврат только ограниченного набора строк. Вы можете добиться этого с помощью ROW_NUMBER() функции в SQL Server, а затем добавить условие фильтра в ИНЕКЕ:

WHERE RowNum BETWEEN @PageNumber * @PageSize AND (@PageNumber + 1) * @PageSize 

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

+0

Итак, мне нужно добавить заказ и использовать @@ ROW_Number? Это замедлит реакцию (заказ стоит дорого) и надеялся избежать этого, но я полагаю, что это улучшит кажущуюся отзывчивость для пользователя. – davids

+0

@davids: Применить порядок в столбце, где определен кластерный индекс. Вы потеряете некоторое время для заказа, но вы получите больше, вернув значительное более низкое количество данных. –

Смежные вопросы