[Moscow.pm] Самый крупный проект, где используется ORM

[Ruslan Zakirov]

2012/3/30 Ivan Petrov <i.petro.77.00 на gmail.com>:
>>> А вот часто некоторые "знатоки" в качестве одного из аргументов против ORM
>>> ссылаются на то, что ORM якобы не применим в крупных проектах.
>> Крупный проект != высоконагруженный проект.
>> ORM слабо применим в высоконагруженных проектах ИМХО. Размер же
>> проекта как таковой особого значения не имеет.
>
> полностью согласен.
>
> когда проект развивается и пока ничего не экономим запросы к ORM
> выглядят однообразно и красиво. то есть один запрос на все случаи
> жизни вроде
>
> resultset('abc')->search({ cde => 'def') })->all
>
> потом когда начинается экономия нагрузки, то начинается добавление
> записей
>  prefetch
>
> затем начинается экономия трафика и добавляются выборки columns.
>
> затем местами еще указан тип join'а и размер выборки.
>
> и далее когда мы смотрим на это все, то получается что запросы к ORM
> мало чем отличаются от запросов к БД. то есть просто иерархия.
>
> ну а когда речь идет об оптимизации самих запросов, то в итоге ORM
> выкидывается нафиг и запросы пишутся вручную (либо для ORM куча VIEW
> пишется).
>
> в итоге в HL-проекте получается что ORM используется только для
> блессинга выборок в объекты. при том что зачастую поверх этих
> выбранных объектов еще OOП инфраструктура наворачивается.
>
> В итоге мы пришли к тому что хелпер генерации SQL-запросов
> (темплейтный язык + именованные плейсхолдеры и помощники) + блесс
> выборок в итераторы - самый оптимум для HL

Вы все правильно описали. Получается, что это итеративный процесс. В
какой-то момент что-то перестает работать как надо и заменяется другой
технологией. И такие примеры от всех крупных игроков на каждом шагу
валяются. "Было у нас так. Уткнулись в это. Покумекали. Переписали
так. Профит."

Уже не рах говорили, что преждевременная оптимизация это плохо.



> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org



-- 
Best regards, Ruslan.