Курсоры ускоренной перемотки вперед SQL Server

Поскольку вы не указали ни тип содержимого запроса, ни правильный запрос JSON. Вот правильный способ отправки запроса JSON:

var arr = { City: 'Moscow', Age: 25 };
$.ajax({
    url: 'Ajax.ashx',
    type: 'POST',
    data: JSON.stringify(arr),
    contentType: 'application/json; charset=utf-8',
    dataType: 'json',
    async: false,
    success: function(msg) {
        alert(msg);
    }
});

Замечания:

  • Использование метода JSON.stringify для преобразования объекта javascript в строку JSON который является родным и встроенным в современные браузеры. Если вы хотите поддерживать старые браузеры, вам может потребоваться включить json2.js
  • Указание типа содержимого запроса с использованием свойства contentType, чтобы указать серверу цель отправка запроса JSON
  • Свойство dataType: 'json' используется для типа ответа, который вы ожидаете от сервера. jQuery достаточно умен, чтобы угадать его из заголовка ответа сервера Content-Type. Поэтому, если у вас есть веб-сервер, который уважает более или менее HTTP-протокол и отвечает на Content-Type: application/json на ваш запрос, jQuery будет автоматически анализировать ответ в javascript-объекте в обратном вызове success, так что вам не нужно указывать Свойство dataType.

Осторожно:

  • То, что вы называете arr, не является массивом. Это объект javascript со свойствами (City и Age). Массивы обозначаются символом [] в javascript. Например, [{ City: 'Moscow', Age: 25 }, { City: 'Paris', Age: 30 }] представляет собой массив из двух объектов.

7
задан Miles D 31 August 2008 в 18:56
поделиться

6 ответов

'Лучшая практика' предотвращения курсоров в SQL Server относится ко времени SQL Server 2000 и более ранних версий. Переписывание механизма в SQL 2005 решило большинство проблем, связанных с проблемами курсоров, особенно с введением опции ускоренной перемотки вперед. Курсоры не обязательно хуже, чем основанный на наборе и используются экстенсивно и успешно в Oracle, МН (ЦИКЛ) / SQL (ЦИКЛ).

'Общепринятое', к которому Вы обращаетесь, было допустимым, но теперь устарело и является неправильным - идут на предположение, что курсоры ускоренной перемотки вперед ведут себя, как рекламируется и работают. Сделайте некоторые тесты и исследование, основывая Ваши результаты на SQL2005 и позже

-2
ответ дан 6 December 2019 в 07:30
поделиться

Это оправдывает надежды для консолидации ответов, данных до настоящего времени.

1) Если во всей возможной, используемой основанной на наборе логике для Ваших запросов т.е. пытаются использовать просто SELECT, INSERT, UPDATE или DELETE с соответствующим FROM пункты или вложенные запросы - они почти всегда будут быстрее.

2) Если вышеупомянутое не возможно, то в SQL Server 2005 + FAST FORWARD курсоры эффективны и работают хорошо и должны использоваться в предпочтении к циклам с условием продолжения.

2
ответ дан 6 December 2019 в 07:30
поделиться

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

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

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

2
ответ дан 6 December 2019 в 07:30
поделиться

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

Вот немного ссылок, которые только были бы верхушкой айсберга, если Вы исследуете эту проблему:

http://www.code-magazine.com/Article.aspx?quickid=060113

http://dataeducation.com/re-inventing-the-recursive-cte/

19
ответ дан 6 December 2019 в 07:30
поделиться

Если Вы хотите еще более быстрый курсор, чем УСКОРЕННАЯ ПЕРЕМОТКА ВПЕРЕД затем использует Статический курсор. Они быстрее, чем УСКОРЕННАЯ ПЕРЕМОТКА ВПЕРЕД. Не чрезвычайно быстрее, но может иметь значение.

-2
ответ дан 6 December 2019 в 07:30
поделиться

"Если вам нужен еще более быстрый курсор, чем FAST FORWARD, используйте STATIC курсор. Они быстрее, чем FAST FORWARD. Не очень быстро, но может иметь значение."

Не так быстро! По данным Microsoft: "Обычно, когда происходили эти преобразования, тип курсора ухудшался до "более дорогого" типа курсора. Как правило, курсор (FAST) FORWARD-ONLY является наиболее производительным, за ним следуют DYNAMIC, KEYSET и, наконец, STATIC, который обычно наименее производителен."

from: http://blogs.msdn.com/b/mssqlisv/archive/2006/06/23/644493.aspx

2
ответ дан 6 December 2019 в 07:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: