да ORM доставляет проблем, 
количество запросов увеличивается на порядок 
а SQL есть SQL, он и разрабатывался как язык для работы со множествами  

мне всетаки кажется, что создавать подобную "смесь" не стоит... предпочитаю работать напрямую с бд

зы но конечно через минимальную прослойку

Это сообщение отредактировал(а) LeoK - 2.11.2009, 17:21

Бесспорно выгода в использовании FW есть, прежде всего это уже хорошо известная(команде) архитектура, документация... если что, то можно подпилить если не устраивает что то, но обязательно задокументировав это. Если использую фреймворк то, стараюсь делать классы как можно независимыми от самого фреймвёрка (или хотябы чтоб в дальнейшем делать как можно меньше изменений), для того чтобы их можно было использовать в других проектах или даже в других фреймворках.

как то это странно    , "некий обскурантизм в действиях" (с)ДМБ

Ну хоть бы написали почему вам так "кажется" ) А то можно подумать, что "не читал, но осуждаю"

ну хотябы потому, что в случае смешанного использования orm и sql собственно теряется сам смысл использования orm. если у нас есть механизм работы с бд, то, имхо, он должен быть один... что если мы например пытаемся встроиться в "прослойку" с бд? например раскидать запросы проксиком с одного сервака на несколько? в случае описанном brother79 придется во первых встраиваться в класс, во вторых перепиысвать custom запросы... если же механизм прослойки один и он минимален, т.е. банальный $db->query($sql), то менять придётся в одном месте и у нас остается один единый интерфейс к бд.

в идеале нужно предусматривать в orm логику, позволяющую вследствии использовать к примеру горизонтальное масштабирование, что не так то просто... ввиду сложности как таковой самой orm + еще механизм масштабирования, который в хайлоад проектах может иметь достаточно сложную организацию.

А кто говорит о смешанном использовании? Что мешает писать кастомные методы с кастомными запросами (в идеале построенными через конструктор ORM) с кастомным маппингом на объекты?

Масштабирование обычно реализуется именно средствами СУБД. Клиент (php) просто понятия не имеет с какой именно ноды пришли данные.




В любом случае, после работы всех ORM все сводится к выполнению запроса. И выполняется он всегда в одном месте. И изменить логику в этом месте не проблемма (если уж сильно прижало, что маловероятно)


В чем сложность кроме сложности самой ORM? Как-то "сложность ORM" очень слабый аргумент, т.к.:
1. Масштабирование в них предусмотрено "из коробки"
2. Напильник никто не отменял. И, если уж вы придумали нестандартных алгоритм масштабирования -- допилите.

solenko, не думаю, что стоит поднимать холивар на тему orm vs sql  ИМХО orm в "чистом виде" опять таки способ усложнить код + лишний код + усложнение запросов + невозможность оптимизации запросов.

Ответьте мне всего лишь на один вопрос - какой смысл городить "решающуювсезадачи" надстройку над sql? преобразовывая объекты в запросы а потом обратно? Думаю, это просто усложняет логику. База есть база, и лучше чем sql еще ничего не придумали...

Добавлено через 3 минуты и 55 секунд

это задача настолько уникальная для каждого проекта, что общие решения просто идут лесом


это идеальный случай... ЭФФЕКТИВНОЕ (!!!) бесконечное гориз. масштабирование невозможно без вмешательства в код!.. опять таки повторюсь, что это очень специфично для каждого проекта

 Общие решения как правило подходят для подавляющего большинства проектов. Так что не идут.

 Идеальный случай для подавляющего большинства проектов как раз подойдет.
А вот БЕСКОНЕЧНОЕ гориз. масштабирование - это идеализированный случай )

MyDarkSide,    Что в этом странного?  Всего лиш стараюсь делать не сильную связь между классами. 

1. без фреймворка действительно сложно работать команде в случаях нехватки опыта, отсутствия опыта работы конкретной группы разработчиков , неопытном ПМе, неграмотном тех задании\ проектной документации.  если вся команда неопытна, можно завалить любой проект

2.  если речь идет о личном сайте Васи Пупкина,  его "мегапартале" для друзей, сайта для продажи слонов и т.д.  фреймворки экономят массу времени, но сами разработчики ничему не учатся, т.к. любой фреймворк ограничивает возможности для ускорения разработки ( варианты с переписыванием кусков ядра не рассматриваются, последующий апдейт ядра не должен добавлять N часов работы программисту, просто чтобы сайт работал).

3. при разработке больших сайтов фреймворк ускоряет получение беты, дает возможность быстро показать клиенту что-то готовое.  Но как правило, все переписывается при первой оптимизации, т.к. в фреймворках упор делается на функциональность, а не на скорость работы скриптов

4. можно и нужно изобретать велосипеды, это процесс обучения. И пусть говорят что 1000 разработчиков отладило код фрейморка, появится 1001 и найдет в том же коде фатальный баг,   1000 обезьян могут ошибаться и как правило ошибаются. 

Необходимо четко знать возможности платформы, требования клиентов  и так же предполагаемой нагрузки на систему. В 50% случаев хватает уже готовых модулей для друпала\кейка, еще в 40% можно что-то в них допилить. 
оставшиеся 10% это узкая сфера, где фреймворки\цмс не приживаются, т.к. задачи очень нестандартные и сложно вписываются в рамки любого написанного софта

Я не спорю, на своих ошибках учиться можно, только есть поговорка про то, кто и н чьих ошибках учится. Это я к слову нужности изобретания велосипеда.

Ещё раз упомяну, что скорость работы большинства PHP фреймворков узким местом не является.

если не является, то скорее:

много трафа на сайт не только радость =)  у Васи никогда не будет столько уников в онлайне чтобы нагрузить сервер или понадобился ровно работающий кластер серверов

я не хочу сказать что фреймворк плохо, но топик стартер спросил 


да, грузит немного серв имхо 

Угу. А Yahoo answers мегапортал для друзей Джерри Янга )