Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
16.10.2014, 18:20
|
|||
|---|---|---|---|
DB2: курсор, зависящий от условия |
|||
|
#18+
То есть, что-то такое Код: plsql 1. 2. 3. 4. Этот код не компилируется: авторMessage: [SQL0104] Лексема C1 недопустима. Допустимые лексемы: GLOBAL. Причина . . . . : В лексеме C1 обнаружена синтаксическая ошибка. Подумал о COALESCE, что-то вроде: Код: plsql 1. 2. 3. 4. 5. 6. но COALESCE вернет первое не-null значение, даже если вывод запроса SELECT P.RRY FROM table1 P отформатировать, чтобы список результатов шел через запятую. Если SELECT P.RRY FROM table1 возвращает одну строку, то эта конструкция работает, но у меня другой случай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 23:11
|
|||
|---|---|---|---|
DB2: курсор, зависящий от условия |
|||
|
#18+
eklm86, Первый вариант не работает, поскольку все DECLARE должны предшествовать первому исполняемому предложению. В зависимости от того, что вы дальше делаете с этими курсорами, можете попробовать так: Код: sql 1. 2. 3. 4. 5. 6. 7. или попросту так: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.10.2014, 12:57
|
|||
|---|---|---|---|
DB2: курсор, зависящий от условия |
|||
|
#18+
Мне подошел второй вариант, спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.10.2014, 18:28
|
|||
|---|---|---|---|
DB2: курсор, зависящий от условия |
|||
|
#18+
eklm86, Я бы предложил отнестись к варианту с "или" осторожно с точки зрения производительности. Preemptive optimization - это, конечно, тоже плохо, но совсем не оглядываться на то, "как оно будет выполняться", не стоит. Полная выборка будет осуществляться table scan'ом (если мы не настояли на обратном в профиле оптимизации). Выборка по RRY - или table scan'ом, или по индексу (если для RRY есть индекс) в зависимости от того, что оптимизатор посчитает более эффективным. Для разных значений @DDY это может быть по-разному ( поэтому иногда правильней указать значение в предикате явно, а не параметром, чтобы оптимизатор строил план исходя из статистики по конкретному значению ). По запросу с условием "WHERE @DDY = '000' OR O.RRY = @DDY" будет строиться единый для обоих вариантов план (грубо - "всегда полный скан таблицы"), что для вариантов с заданным @DDY может оказаться очень неэффективным. В общем, если количество строк в таблице хоть сколько-нибудь существенно и сканирование по индексу эффектиивней, попробуйте использовать: Код: sql 1. 2. 3. 4. это разобъёт план на две самостоятельные ветки (проконтролируйте только, что при @DDY <> '000' первый скан действительно не будет физически выполняться). Возможно, лучше формировать запрос динамически (если различных значений @DDY немного и это не повлияет сильно на кэш запросов): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Это эффективно, если у нас есть значения RRY с сильно разной селективностью (будут строиться разные планы). Похожего результата можно добиться партиционированием по RRY (даже оставляя значение параметризованным, а запрос - статическим). Но вообще, я не представляю себе ситуации, где можно использовать курсоры, но нельзя выбрать тот или иной, используя условные языковые конструкции. Разве что, текст одной и той же процедуры пишут два разных кодера, и существует некоторая "name convention", как API по передаче информации из первой части процедуры во вторую. Но это, конечно, в корне неправильно. Для некоторых ситуаций (с рядом ограничений) можно вообще вот так: Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=43&tablet=1&tid=1600967]: |
0ms |
get settings: |
13ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
105ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 292ms |
| total: | 490ms |

| 0 / 0 |
