Вячеслав ЛюбомудровСамое смешное, что простое добавление ORDER BY нисколько не утяжелит запрос (никто не запрещает использовать и хинты), но всегда гарантирует правильный результат
Oh my god...
Перечитайте моё сообщение.
Не работает тут
ORDER BY , понимаете?
Oracle не поддерживает передачу полей из запроса во вложенные запросы
FIELD SUBQUERY .
Вот так:
1.
2.
3.
4.
5.
SELECT (
SELECT dummy
FROM dual di
WHERE di.dummy = do.dummy
)
FROM dual do
работает.
А вот так:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SELECT (
SELECT dummy
FROM (
SELECT dummy
FROM dual di
WHERE di.dummy = do.dummy
ORDER BY
dummy
)
WHERE rownum = 1
)
FROM dual do
не работает.
Я же не против
ORDER BY как такового :)
ORDER BY — отличная конструкция, ею отсортировано уже не менее миллиарда запросов в мире.
ORDER BY обеспечивает правильный порядок фамилий в зарплатной ведомости.
ORDER BY выдаёт финансовым аналитикам отсортированный список решений.
Без
ORDER BY мы бы запутались в выписке телефонных переговров Би-лайн...
Да чего уж там, очень много вещей, к которым мы привыкли сейчас, возможны только благодаря
ORDER BY !
Но только в тех случаях, когда она не работает, надо не искать гарантий, а что-то делать.
Вячеслав Любомудров
Еще одно соображение - есть любители использовать обработчик WHEN OTHERS THEN := значение по-умолчанию, дескать не нашли мы требуемого значения (NO_DATA_FOUND) или их больше одного (TOO_MANY_ROWS) или по формату не приводится/длина не та (VALUE_ERROR) или еще чего-нибудь, не удовлетворяющее нашим проверкам, короче, неподходит нам эта строка - нафига все перечислять, просто напишу WHEN OTHERS. А строка-то подходит, просто индекс UNUSABLE. Это ведь тоже неправильный результат.
Я к таким любителям не отношусь и никому так делать не советую.
Однако к сортировке запросов это не имеет ни малейшего отношения :)
Вячеслав Любомудров
Конечно, можно разволноваться и кричать, что все это криворукие админы/программеры, но, к сожалению, это встречается на каждом шагу. Поэтому программа должна себя вести как лифт: Аркадий и Борис Стругацкие. Сказка о тройке...
Но монтеры со своей стороны должны обеспечивать бесперебойность. Ничего, понимаете, ссылаться на объективные обстоятельства. У нас лозунг: "лифт для всех". Не взирая на лица.
Лифт должен выдержать прямое попадание в кабину самого необученного академика .
Ну это...
Мне неловко вам напоминать такую очевидную вещь, но если
CBO , даже безо всяких хинтов, и с аккуратнейшим использованием
ORDER BY , вдруг да и решит использовать индекс, который находится в состоянии
UNUSABLE , то запрос вылетит по той же самой
ORA-01502 .
Это к вопросу о лифте, который выдерживает прямое попадание
CB ... простите, академика.
Хотя что это я.
Ведь у всех хороших програмистов, читавших Стругацких, процедуры, несомненно, корректно обрабатывают
ORA-01502 (и именно её), без использования
WHEN OTHERS .
Не так ли? :)
А если серьёзно, то программа должна себя вести не как лифт. Программа должна вести себя так, как прописано в ТЗ.
Если в ТЗ прописано, что программа должна быстро работать в 99,99% случаев, при этом допускается её отказ в 0,01% случаев, — то делать надо так, чтобы она работала быстро.
Если в ТЗ прописано, что программа должна работать в 100% случаев, то надо делать так, чтобы она работала правильно.
И опять же... Вот вы говорите: мол, админ может решить удалить или переименовать индекс. Тут, замечу я вам, проблема не в сортировке или хинтах, тут проблема в админе.
Как это так: он решил переименовать, или, тем более, удалить
уникальный индекс?
Хотя, конечно, бывают и такие места, где админам дозволено переименовывать и даже удалять индексы. Я не буду критиковать чужие правила, скажу лишь, что даже тут возможны варианты.
Скажем, так:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
DECLARE
cnt NUMBER;
index_unusable EXCEPTION;
PRAGMA EXCEPTION_INIT(index_unusable, - 1502 );
BEGIN
BEGIN
SELECT NULL
INTO cnt
FROM dba_indexes
WHERE owner = SYS_CONTEXT('userenv', 'current_schema')
AND index_name = 'UX_RATE_CURRENCY_DATE';
EXCEPTION
WHEN no_data_found THEN
RAISE index_unusable;
END;
OPEN :cur
FOR SELECT (
SELECT /*+ INDEX_DESC (r ux_rate_currency_date) */
rte_rate
FROM t_rate
WHERE rte_currency = acm_currency
AND rte_date <= acm_date
AND rownum = 1
) * acm_sum
FROM t_accmove;
EXCEPTION
WHEN index_unusable THEN
OPEN :cur
FOR SELECT (
SELECT /*+ FULL(r) */
MAX(rte_rate) KEEP (DENSE_RANK LAST ORDER BY rte_date)
FROM t_rate r
WHERE rte_currency = acm_currency
AND rte_date <= acm_date
) * acm_sum
FROM t_accmove;
DBMS_OUTPUT.put_line('Администратор базы данных, козлина тупая, чё-то сделал с уникальным индексом,');
DBMS_OUTPUT.put_line('от которого, вообще-то, зависит логика работы базы.');
DBMS_OUTPUT.put_line('Из-за этого ваша программа работает медленно, а скоро ещё и наделает ошибок.');
DBMS_OUTPUT.put_line('Позвоните хозяину фирмы, пускай он выпишет администратору п' ||
CHR( 232 ) || CHR( 231 ) || CHR( 228 ) || CHR( 238 ) || 'в, да покрепче');
END;
Чем плохо? :)
У меня , кстати, такая конструкция, без
ORDER BY , уже года три работает на
production в чуть больше чем тридцати местах.
Пока, тьфу-тьфу, держимся :)
