T-SQL, несколько обновлений в запланированном задании - PullRequest
Новая
       43

T-SQL, несколько обновлений в запланированном задании

3 голосов
/ 18 ноября 2011

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

Можно продемонстрировать образец (как он есть в настоящее время)следующим образом: 

UPDATE TEST_TABLE SET STATE = 1
WHERE {some condition}

UPDATE TEST_TABLE SET STATE = 2
WHERE {some condition}

UPDATE TEST_TABLE SET STATE = 3, SOME_OTHER_COLUMN={value}
WHERE {some condition}

WHILE(some condition)

BEGIN
UPDATE TEST_TABLE SET STATE = 4, SOME_OTHER_COLUMN={value}

WHERE {some condition}

END

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

Мне также пришлось использовать цикл while вместо курсора(из-за низкой производительности), поскольку необходимо было обновить данные в этой таблице небольшими группами в зависимости от этих условий.

При условии, что весь запрос заключен в транзакцию и блок try-catch.

И, наконец, вот мой вопрос: поскольку это будет запланированное задание, которое будет выполняться ночью, производительность для меня не является главным приоритетом.Однако я не мог понять, как выполнить ту же операцию с помощью более чистого и более эффективного (с точки зрения производительности) запроса.Мне нужны некоторые советы.Обратите внимание, что области {некоторые условия} содержат подзапросы с функцией EXISTS.Таким образом, оригинальный код выглядит гораздо более грязным, чем этот.Заранее спасибо.--Ozan

1 Ответ

1 голос
/ 18 ноября 2011

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

Даже если она достаточно велика по сравнению с тем, где предложение WHERE запроса работает эффективно из-за индексов, вы можете быть в порядке.

Вы можете объединить запросы - если предложения WHERE совпадают, то вы можете объединить их.

IMO, чем проще код для чтения, тем проще для негоподдерживать.Если вы не получаете значительного прироста производительности, то консолидация на самом деле не имеет смысла.

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

Самое большое, что бросается в глаза, это то, что вы попробовали CURSOR и теперь изменили его наWHILE петля.

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

РЕДАКТИРОВАНИЕ на основе комментария OP

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

...