Horsun Vlad пишет:
Не сильно заморачиваюсь этим вопросом, ибо делаю отдельный prepare
крайне редко, можно сказать никогда в штатной работе.
Если ты его не делаешь явно - это ещё не значит, что он не
делается вообще
Разумеется, оно делается сервером.
Т.е. переоптимизирует при каждом выполнении ? Некузяво это, имхо
Ну, смотря что с чем сравнивать. За то отсутствует понятие "плохого
индекса", можно смело делать индексы на поля типа статусов, как описано
в начальном посте. Мною визульно накладные расходы на оптимизацию на
большинстве задач не обнаружены.
А если с явным препаре ?
Вот что есть в доке про preparing:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/dbpgen9/00000020.htm
Пишут, что generate an access plan if the statement involves joins or
subqueries.
Что за этим скрывается на самом деле - не знаю. Но похоже на запросах с
параметрами без явного prepare план строится в зависимости от значений
параметров.
Следует ещё понимать, что в ASA (да и в MSSQL) процедура -
это набор _отдельных_ statement'ов, каждый из которых имеет
свой план выполнения, а у нас - процедура есть один statement
с единым планом выполнения
Можно подробнее эту мысль? Что значит план для процедуры, в которой
внутри куча разных, возможно несвязанных между собой запросов?
