> > On Fri, Oct 28, 2011 at 12:09:42PM +0400, Михаил Шогин wrote: > > > > > > > Мда, долгая дискуссия. > > > > > > > > ORM - зло! > > > > > > > > Что такое SQL ( в простом определении ) - это то что мы хотим > получить и > > > > ПУТЬ получения данных. > > > > При использовании ORM и конструкторов запросов, мы не черта не знаем > > > каким > > > > путем мы получаем данные, а это самое главное. > > > > Как оптимизировать запросы? Как закреплять планы выполнения? > > > > Ведь в каком то случае лучше использовать HASH JOIN, а в каком то > NESTED > > > > LOOP. > > > > > > > > Даже банальная фильтрация данных может идти несколькими различными > > > путями: > > > > - table full scan > > > > - index range scan + table access by rowid > > > > - index range scan > > > > - index full scan > > > > > > > > Как всем этим управлять? > > > > > > Фишка здесь в том что такой микроскоп нужен на 1 из 100 запросов. > Хватай > > > голый $dbh из DBIC и делай что хочеш. Ведь нигде не сказано что раз > DBIC > > > так всегда DBIC. Надо все таки уметь сообразить когда пора положить > молоток > > > и взять отвертку :) > > > > > > > Хех, нет, у нас не так. Запросы оптимизируются перед использованием в > коде. > > + выставляются хинты для быстрого выявления тормозных запросов. > > Хех, ну если для вашей конторы такой уровен premature optimisation привидно > оптавдан (ибо никогда не может быть *реально* оправдан) - то с DBIC, да и > вообще любым генератором вам не по пути :) > Оптимизация становится хорошей привычкой и выполняется как часть процесса ;)
Точно так же как и в тестировании есть хороший паттерн Red - Green - Refactor имеем и применительно к SQL SQL - Explain - Optimisation Конечно генераторы пробовали, но поддержка, понимаемость кода падает прямо пропорционально объему последнего. Но надо сказать, что все это хорошо в случае жестких стандартов оформления Perl, SQL и т.п. В этом случае читаешь чужой код ка свой собственный -- С уважением Михаил Шогин.
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
