SQL или PL/SQL?

[egorius]

Наблюдаю интересную картину: абсолютное большинство отчётов и программ под Oracle Applications написано не в декларативном SQL-стиле, а в традиционном процедурном стиле PL/SQL. Даже родные оракловые пакеты этим грешат.

А между тем, это чревато потерей производительности, причём иногда совершенно катастрофической. Беглый взгляд в трассу (как в

Comments

[hardsign]

метрика, пусть не идеальная, но вполне применимая на практике, с помощью которой можно сравнивать запросы

Слышал про такую штуку как ожидания? Вот посчитай время и количество ожиданий при одноблочном и многоблочном чтении, будет о чём задуматься. И с латчами то же самое.

Как посчитать переключения контекстов - не знаю, но твою кривую функцию можно как минимум написать чуть менее криво_чем, если уж SQL товарищи писать не умеют:

create or replace function get_authors(p_book_id number)
return varchar2
is
type t_name is table of writers.name%TYPE index by binary_integer;
v_name t_name;
begin
select w.name
bulk collect into v_name
from writers w, authors a
where a.book_id = p_book_id and w.writer_id = a.writer_id
order by a.seq_num;
if v_name.count>1 then
return v_name(1)||' и др.';
else
return v_name(1);
end if;
end;

Количество переключений контекста сокращается вдвое!

А ещё время выполнения PL/SQL кода предсказуемо, в отличие от SQL. Помню, делал халтурку® для одной конторы, так я там написал всё на SQL. Они сказали - иногда работает шустро, а иногда - хоть плачь. А им нужно реальное время.

Конечно, это был Ъ™ 8i, да и вообще использование реляционной СУБД как системы реального времени выглядит по меньшей мере странно, но думаю, что формсы твои любимые написаны на PL/SQL именно из этих соображений. Из чего, разумеется, не следует, что надо упобобляться братьям-индусам.

Распараллеливание плохо потому, что для того, чтобы direct path read был возможен, надо, чтобы все блоки были сброшены на диск, т.е. перед каждым запросом выполняется маленький такой checkpoint. Но если разделить таблицы, которые регулярно абдейтяццо и таблицы, по котоым строятся отчёты, то пуркуа бы и не па даже на гибридной системе :)

[egorius]

Насчёт ожиданий, боюсь, не всё так просто. Сравнить одноблочные чтения с многоблочными ещё можно, хотя для этого, наверное, понадобится отдельный пример. Подумаю_над. А вот latch free можно и вообще не заметить, железяки-то мощные... Вот когда таких кривых отчётов много и система начинает загибаться - другое дело, но до этого лучше не доводить :)

Про переключение контекстов тоже есть над чем поразмыслить. Если получится продемонстрировать разницу на твоём примере, то завтра же высылаю $10.

А с распараллеливанием у нас облом, потому что хрен-то там чего разделишь. Да на наших жалких объёмах и без распараллеливания всё может очень шустро работать, если, конечно, зарядить могзи.