SQL или PL/SQL?

[egorius]

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

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

Comments

Имею сказать

[hardsign]

0. Оформление кода™ Я так же оформляю, и даже шрифт lucida console

[egorius]

Перво-наперво, спасибо за многабукф по делу.

ъ) Во всём с тобой соглашусь, кроме одного. Ты выводишь на первое место многоблочное чтение, а я всё-таки считаю, что уменьшение логических чтений важнее. Их уменьшение означает, что мы будем делать меньше бесполезной работы. Если при этом ещё и возрастёт скорость за счёт многоблочных чтений или распараллеливания - ну совсем хорошо. Но даже если бы не возрасла, всё равно было бы неплохо. В общем, мы-то понимаем, что на самом деле одно другое очень удачно дополняет

[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

[egorius]

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

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

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

[anonymous]

Аффтар жжот!
"сериализуется с помощью защелок" - это упорядочивается с помощью триггеров, что ли? :Е
Сама идея, что микрооптимизация, особенно ориентированная на "знание" внутренней структуры, зачастую ухудшает макропоказатели, в-общем, не нова.
Однако есть наблюдение о ходе эксперимента, точнее о собираемой статистике: оптимизируемый параметр (consistent gets) может не вполне отражать картину, если учитывает только обращение к данным "на носителе", но не учитывает внутренние манипуляции, которых во втором случае гораздо больше. Даже с учетом того, что ОЗУ намного быстрее чем диск, нельзя исключить ненадежность результатов.
СП

[egorius]

Защёлки - это latches, оракловый механизм ограничения одновременного доступа к памяти. В статье Миллсапа, на которую я ссылаюсь, они неплохо описаны.
Да, внутренние манипуляции по обработке того, что прочиталось, действительно не учитываются. Действительно, обработка одного блока может занимать больше времени, чем обработка другого. Тем не менее, этот параметр всё-таки вполне адекватен, что подтверждается практикой. И у него есть огромный плюс: его легко измерить.

[n1919]

SQL-запрос в 1000 строк когда-нибудь видели?
то еще зрелище...

[egorius]

Не только видел, но и писал.
И должен сказать, что зачастую это всё равно лучше, чем процедурный код. Другое дело, что на SQL надо уметь писать аккуратно, чтобы эти 1000 строк не были одним большим месивом. Впрочем, месиво - оно и на процедурном языке месиво...