<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">> Мда, долгая дискуссия.<br>
><br>
> ORM - зло!<br>
><br>
> Что такое SQL ( в простом определении ) - это то что мы хотим получить и<br>
> ПУТЬ получения данных.<br>
> При использовании ORM и конструкторов запросов, мы не черта не знаем каким<br>
> путем мы получаем данные, а это самое главное.<br>
> Как оптимизировать запросы? Как закреплять планы выполнения?<br>
> Ведь в каком то случае лучше использовать HASH JOIN, а в каком то NESTED<br>
> LOOP.<br>
><br>
> Даже банальная фильтрация данных может идти несколькими различными путями:<br>
>  - table full scan<br>
>  - index range scan + table access by rowid<br>
>  - index range scan<br>
>  - index full scan<br>
><br>
> Как всем этим управлять?<br>
<br>
</div></div>Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов. Хватай<br>
голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз DBIC<br>
так всегда DBIC. Надо все таки уметь сообразить когда пора положить молоток<br>
и взять отвертку :)<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br></div><div>Хех, нет, у нас не так. Запросы оптимизируются перед использованием в коде.</div><div>+ выставляются хинты для быстрого выявления тормозных запросов.</div>
<div><br></div><div><br></div></div><div><br></div>-- <br>С уважением<br>Михаил Шогин.<br>Tel: +7 915 0311328<br>ICQ: 266776394<br><br>