Диагноз - ORM :-)

[atv]

Приходим к тому, что для таких задач в конечном итоге будут использоваться SQL-запросы и получаем мешанину из SQL запросов и обращений к ORM в коде

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

В тоже время, мешанина "из SQL запросов и обращений к ORM" остаётся мешаниной только если её не организовать. Когда будут чёткие критерии, какие данные каким способом выбираются, будет чёткое представление о том, где вносить изменения.

-~{}~ 30.03.07 12:26:

Хочу добавить, что рано или позно приходиться сталкиваться с недостатком производительности. Например на сотнях тысяч записей тормозить будет не только ORM. Сама БД тоже начнёт тормозить при таком количестве вычисления, а значит, рано или поздно, придётся применять обходные решения. Например, в случае с вычислением суммы всех заказов для данного служащего, можно использовать вычисления за отчётный период и хранить эти данные в отдельной таблице.

Так вот, обходные решения можно принимать начиная не с сотни тысяч записей, а с тысячи, и тем самым не выводить ORM из игры.

Это известный принцип, если нужно увеличить производительность системы, необходимо увеличить расход памяти. Слава богу на винтах памяти хватает

 

[bkonst]

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

А вообще, ваш вариант тоже вполне жизнеспособен. В своей нише, понятно.

 

[hermit_refined]

Если приложению потребовалось "выбрать сумму заказов по данному продавцу", то лучше сделать это обычным способом, так, как будто перед вами обычная коллекция объектов, и у неё за спиной нет БД, т.е. проссумировать сумму в цикле.

ага, выбирать все данные из бд, и реализовывать логику запросов в скрипте.

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

 

[bkonst]

hermit_refined
... в своей нише. Есть и скрипты, для которых такие вычисления не нужны. Но мало.

И вообще, лучше уж иметь слегка расширенный ActiveRecord + IdentityMap, чем не иметь вообще ничего.

-~{}~ 30.03.07 16:32:

P.S. Ничего, рабочая неделя ужк заканчивается. Скоро отдых.

 

[atv]

hermit_refined, это опять ты?!! Ты снова ошибся разделом. Тебе как зашёл, так сразу в самый низ, Offtopic называется.

назвать ORM это нельзя

Ооо... Может вы сформулируете нам, что можно называть ORM, а что нет? Или опять скроетесь в кустах... отшельник вы наш

интересно, почему тема в теории, а не в юморе.

Админы переставили.

 

[hermit_refined]

Тебе как зашёл, так сразу в самый низ, Offtopic называется.

куда мне, я уж как-нибудь без вас разберусь.
и истеричных оскорблений, pls, не надо.
тем более, что по существу, видимо, возражений нет.

Может вы сформулируете нам, что можно называть ORM

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

 

[whirlwind]

Вот смотрю я на разные ормы, что в лимбе (хотя там якобы не орм), что в пропеле что здесь - нет почти самого основного удобства - из класса модели непонятно что же он из себя представляет. Нет достаточной информации об атрибутах, то она из таблицы берется, то из XML. Весь цимус концентрации ОО модели в одном месте (и как следствие легкости восприятия) пропадает - обязательно нужно лезть кудато что бы что-то уточнить.

PS. Коллекции вполне заменяются одним ссылочним атрибутом по ангалогии как в БД. И нигде ничего не дублируется, и развернуть на автомате можно без ручных джойнов.

 

[atv]

тем более, что по существу, видимо, возражений нет.

Весь в внимании, слушаю ваши возражения по существу.

куда уж мне тут одному пытаться... да и зачем?..

Действительно, зачем... Сказать то нечего, а сказанное подкрепить нечем. Как я и говорил, гавкнуть гавкнул, а аргументировать нечем.

Ну, раз тебе больше нечего сказать (хотя настоящему мужчине всегда есть что сказать ), давай прощаться.

Пока.

-~{}~ 30.03.07 16:41:

нет почти самого основного удобства - из класса модели непонятно что же он из себя представляет.

Так ничего не мешает указать их в классе, если я правильно понимаю о чём ты.

Коллекции вполне заменяются одним ссылочним атрибутом по ангалогии как в БД. И нигде ничего не дублируется, и развернуть на автомате можно без ручных джойнов.

Я не совсем понял к чему это сказано. Можно чуть подробнее.

 

[whirlwind]

Однако с ним я не согласен - уже на небольших количествах записей (по моим экпериментам - от сотни и выше) затраты на получение всех данных от сервера, инициализацию и обработку объектов становятся очень даже заметны; при тысячах / десятках тысяч записей - будут жестокие тормоза.

Неправда Ваша. Задача ОРМ сделать как можно меньше запросов. Если сама она не может угадать в каком случае как удобнее выбирать, значит нужно предоставить удобные средства для программиста. Это возможно когда в конце концов большинство оторвутся от LazyLoad и подумают в сторону BulkLoad

Я не совсем понял к чему это сказано. Можно чуть подробнее.

да это собсно дополнение к сказанному zerkms

 

[camka]

atv
А не могли бы вы привести реальный запросы к базе, которые идут непосредственно к БД серверу?

 

[hermit_refined]

atv
ох... я высказал самое существенное и достаточно очевидное возражение - повторю для вас подробно - перенос логики всех мало-мальски сложных выборок из бд в скрипт, путем загрузки всех строк таблиц, необходимых для получения результата - безумие, прежде всего с точки зрения производительности, хотя и об объеме дублирующегося кода для реализации этих выборок тоже не стоит забывать.

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

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

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

 

[atv]

А не могли бы вы привести реальный запросы к базе, которые идут непосредственно к БД серверу?

Все запросы однотабличные вида:

SELECT seller_id, seller_name FROM sellers WHERE seller_name = 'Seller 1'

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

Ты всё никак не угомонишся? Ну ладно. Позволю себе напомнить, что разговор касался не "всех мало-мальски сложных выборок", а тех, которые не вписываются в область применения ORM. Об этом я уже говорил выше.

вас интересует, что должна сделать ORM, когда нам необходимо получить "выбрать сумму заказов по данному продавцу"?

Ничего не должна. Нет такой сущности как "сумма заказов по данному продавцу". Заведите её в БД и тогда она попадёт в область применения ORM. Ещё раз повторю, ORM не должна поддерживать все возможности SQL, так как у них разное предназначение. Ничто не справиться с предназначением SQL лучше самого SQL. Это понятно?

и перестаньте юродствовать - вы либо честно сливаете, либо внятно изъясняетесь, а не демонстрируете свои знания дворовой риторики.

Ой, ты что обиделся? Ну извини, я не думал что ты такой чувствительный. Такие самоуверенные люди ("элементарная трех-четырех часовая реализация на коленке"), обычно не такие уязвимые.

Кстати, всегда было интересно узнать о методологии разработки на коленке. TDD изучал, XP интересовался, ну там ещё кое чего, а вот про коленку... Может поделитесь опытом?

 

[hermit_refined]

Позволю себе напомнить, что разговор касался не "всех мало-мальски сложных выборок", а тех, которые не вписываются в область применения ORM.

поправка - в область применения вашего ORM.

Нет такой сущности как "сумма заказов по данному продавцу"

в казуистику не втянете.
хотите сущности? да без проблем.
"выбрать всех продавцов, у которых сумма заказов >= ..."

Ничто не справиться с предназначением SQL лучше самого SQL.

ORM предназначена для предоставления данных для приложения.
...
лучше сделать это обычным способом, так, как будто перед вами обычная коллекция объектов

хм, это один и тот же человек писал?
если берете те или иные свои слова обратно, делайте это явно.

Ой, ты что обиделся? Ну извини, я не думал что ты такой чувствительный.

перечитайте, pls, мои комментарии и свои.
вы реагируете явно неадекватно, позволяя себе истеричные переходы на личности, никак не связанные с предметом обсуждения, а по существу - неудобству и (мягко говоря) неэффективности выполнения нетривиальных запросов - слышу только риторические парирования.
коструктива добавить не хотите, не?..

насколько я знаю, так ведут себя люди, которые отчасти сознают свою неправоту, лишь признаваться в ней не привыкли.

TDD изучал, XP интересовался, ну там ещё кое чего,

обычная песня.
да вот только нет мне дела до вашего опыта.
на этом форуме я по постам о человеке сужу.

 

[whirlwind]

hermit_refined
> выбрать всех продавцов, у которых сумма заказов >= ...

$loader = new BulkLoader();
$loader->setAutoGroup();
$order = new Order();
$loader->attachEssence($order);
$loader->attachEssence(new Seller());
$loader->addIncludeList("Order",Array());
$loader->getQuery()->having()->addChunk(
      new SqlSumCond($order,"amount",$discount,SqlComparison::GREATER_OR_EQUAL));
$loader->fetch();
while ( $loader->next() )
        echo $loader->get("Seller")->asString(),"\n";

8)

 

[hermit_refined]

whirlwind
как-то так ;-)
на мой вкус, конечно, несколько громоздко/некомпактно и избыточно (вообще говоря, нам достаточно сказать, что мы хотим получить Seller, у которых выполняется условие new SqlSumCond($order, ...), остальная информация у ORM уже есть - хотя понятно при этом, что уже для трех таблиц такой красоты достичь будет значительно сложней), но идеальной во всех отношениях ORM, увы, я не видел и не знаю...
... если бы знал, занялся бы реализацией в виде расширения на С (там, кстати, больше пространства для фокусов), что позволило бы расширить область применения, а так остается только удивляться, почему весь мир жалуется на тяжеловесность всех нормальных ORM, а ни одного расширения до сих пор никто не написал.

в контексте же темы - я как раз пытаюсь объяснить, что - в частности - без подобной функциональности ORM немыслим.

 

[jonjonson]

Попробую высказать крамольную мысль (а может просто тупую). ORM не нужен, если нет автоматической генерации кода средствами RAD. То есть он хорош только комплексно с такими средствами.

Объектно ориентированный подход в данном случае выглядит как парик на не объектной БД. Где-то его можно пригладить, а где-то он всегда выглядит не естественно. А самое главное, при определённой сложности его придётся снять и воспользоваться чистым SQL. Это конечно скорее эмоциональное замечание, но оно как минимум отображает действительность. Думаю, среди участников топика окажется больше желающих поправить SQL запрос, чем нечто на ORM. Не так ли, господа?

И наконец... Программирование требует простоты. SQL позволяет более простыми средствами описать то, что происходит в нём, нежели ORM накладки. При этом можно использовать родную мощь SQL. Программисту знающему php и SQL для использования ORM нужно изучать ещё один язык. Построение же запросов через ORM - это написание кода на языке ORM. Вспомните работу с файлами или потоками. ORM ещё сложнее.

Это конечно ИМХО. Развитие средств разработки очевидно заставит и меня обратиться к ORM и засовывать через них объекты в не объектные БД. А может будет придумано нечто более гуманное.

 

[atv]

поправка - в область применения вашего ORM

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

"выбрать всех продавцов, у которых сумма заказов >= ..."

Сумма заказов, это вычисляемое значение, а не сущность. Как ещё это можно объяснить? Данная функциональность в БД является надстройкой на реляционной моделью, а ORM отображает только модель. Если пытаться воспользоваться этой надстройкой БД в ORM, то, как правильно говорит jonjonson, ORM превращается в парик, чем и отпугивает.

хм, это один и тот же человек писал?
если берете те или иные свои слова обратно, делайте это явно.

Нет в моих словах противоречия. "ORM предназначена для предоставления данных, а не вычислений". Поэтому вычисления "лучше сделать обычным способом, так, как будто перед вами обычная коллекция объектов". А при возникновении проблем с производительностью применить те же решения, которые применяются в БД. В основном, с помощью избыточных данных.

вы реагируете явно неадекватно, позволяя себе истеричные переходы на личности

Неужели ты бросил попытки уколоть меня. Долго до тебя доходило.

коструктива добавить не хотите, не?..

Нормально поговорить захотелось? Так начинай, об чём вопрос, я всегда за!

jonjonson, местами несогласен, но в целом, я тоже придерживался такого мнения до определённого момента. Теперь же я хочу провести более чёткий водораздел между тем что должна делать ORM, и тем чего не должна.

 

[whirlwind]

> на мой вкус, конечно, несколько громоздко/некомпактно и избыточно

Ну щас заменю имена переменных на односимвольные, будет компактнее. Добавлю в BulkLoader делегат для having->addChunk будет еще компактнее. 2 вызова attachEssence заменю на один с массивов - еще компактнее. В итоге я покажу тебе три строки и попробуй сказать что некомпактно. В коде все решается хелперами, а вот в SQL-е придецо все ручками вбивать. Про избыточность эт ты зря. Как раз здесь нет избыточности свойственной для SQL запроса. Пример приведен такой, что бы можно было понять что происходит. А плюсы у ОРМа совсем другие, нежели обскакать SQL, если это еще непонятно.

>хотя понятно при этом, что уже для трех таблиц такой красоты достичь будет значительно сложней

Не вижу никаких проблем ни с тремя ни с десятью таблицами. Приводи ситуацию - напишу реально-работающее решение.

Вообще тема такая, что без реального "прощупывания" спорить бесполезно. Помойму в этой теме никто кроме zerkms не представляет реальных трудностей возникающих при работе с ORM. Они возникают как раз далеко не на селектах.

 

[atv]

Помойму в этой теме никто кроме zerkms не представляет реальных трудностей возникающих при работе с ORM. Они возникают как раз далеко не на селектах.

Ну так давай поговорим об этом. Какие трудности ты имееш ввиду?

 

[zerkms]

ты приводил код

$orders->setFilter("sum = 100");
$customers->setFilter("name = 'Customer 1'");
foreach ($sellers as $seller) {
    print $seller->name;
}

этот код предваряет инстанциация этих объектов. очень непривычно - что манипуляции мы производим над $orders и $customers, а изменяются $sellers.

из собственного опыта (из моего орм) - гораздо более приятным использованием я вижу что-то типа:

$orders = $seller->getOrders();
foreach ($orders as $concrete_order) {
echo $concrete_order->getCustomer()->getName();
}