Какие запросы мешают вам использовать ORM?

[Develar]

whirlwind
Спасибо за дискуссию, раньше сомневался в ORM - а теперь более менее ясно.
Вы действительно не используете ни одного триггера? А хранимые процедуры?

 

[whirlwind]

>не используете ни одного триггера

Для бизнес-логики - нет. Для системных фич - да.

-~{}~ 28.09.06 15:57:

В догонку

Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model

http://java.sun.com/blueprints/patterns/MVC-detailed.html

ORM = данные + логика
ORM != данные
ORM != логика

 

[fisher]

ORM-инфицированного не переубедить. сам должен допереть. со временем. ничего личного ребят.
чтоб не быть голословным.
возмите список минусов из документа по ссылке ниже и напишите почему они все вместе не являются причинами, по которым не стоит использовать ORM. почти никогда.
http://orm.net.ru/wacko/wakka.php?wakka=PlusesAndMinusesOfOrm

 

[Mich]

Все это уже обсуждалось на предыдущих 5 страницах.

 

[fisher]

а. круто. узбеков

 

[Mich]

и тебе таджиков =)

 

[whirlwind]

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

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

Достаточно взлянуть на эти перлы

[skip]

Ну в общем то видно что у чувака предвзятое мнение.

 

[bkonst]

fisher
Если нужна оптимизация на таком уровне - не используйте ORM, пишите руками. Только вот она обычно не нужна, оптимизация алгоритмов дает куда больше.

п.2 из списка "минусов" легко решается ORM, использующими генерацию кода, п.3 - использованием персонала, способного обучаться, п.4 и п.1 - вопрос реализации ORM; так как ORM не пишется для каждого нового проекта заново, накладные расходы не так велики. Таким образом, эти пункты "все вместе не являются причинами, по которым не стоит использовать ORM".

 

[fisher]

2whirlwind:

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

>>По мне так это полный бред, написанный сгоряча
>>человеком у которого проблемы с ООП

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

 

[bkonst]

...Проблема, кстати, стара как мир - "ручная" оптимизация против автоматизации. При появлении достаточно приличных инструментов (ORM) отпадет сама собой.

 

[fisher]

>>Только вот она обычно не нужна,
>>оптимизация алгоритмов дает куда больше
Вы что, это серьезно????

>>п.3 - использованием персонала
вопрос в лоб - был ли у Вас опыт руководства. да/нет.

>>п.2 из списка "минусов" легко решается ORM,
>>использующими генерацию кода
Вы увы не очень. Потому что речь идет не о геренации SQL-кода вместо динамического "собирания" его в процессе выполнения, а о переносе логики в триггеры и процедуры

>>п.4 и п.1 - вопрос реализации ORM
п.1 это то что бедный спирит пробовал вам пионерам втолковать. пожалуйста, в псевдокоде, напишите решение. вот чтоб без трепа только, а.

п.4. мне вот очень интересно, вы вообще понимаете для чего вы программируете? вы платите за трафик? за процессорное время? вы понимаете почему увеличение 10% производительности может принести вам колоссальный выигрыш?

и извините за "пионеров", но просто наболело. ничему не учитесь.

 

[bkonst]

Оптимизация алгоритмов - да, серьезно. Представьте себе. Естественно, при более сложной задаче, чем "выбрать записи с 1 по 10".

п.3. Да. Небольшой. Периодически провожу собеседования, истерически смеюсь после них. И? Если человек неспособен обучаться, он завалит что угодно, так как обучение требует не только ORM. Новая библиотека, используемая в проекте - обучайся, переход на новую версию языка / библиотеки / СУБД - обучайся. Странно, да?

п.2. Отлично. Пусть так. Как уже спросили ранее, почту будем из базы рассылать? К сожалению, ссылка на условия проведенного теста умерла, так что покритиковать условия не получится.

п.1. Уже писался. Раньше в теме. Дайте модель - напишу в псевдокоде и запрос про рестораны (а то что-то не помню в SQL условий вида "отменная вегетарианская кухня")

п.4. не относится к процессорному времени и трафику. Он относится к времени разработки ORM.

вы понимаете почему увеличение 10% производительности может принести вам колоссальный выигрыш?

А вы понимаете, что увеличение времени разработки на 300% и стоимости поддержки на 50% ради увеличения производительности на 10% может этот выигрыш съесть? Вы понимаете, что есть разные задачи? Есть задачи, для которых и 1% производительности важен, а есть такие, где важнее гибкость, простота поддержки и внесения изменений?

... Вообще, fisher, Фанат из вас хреновый. ORM - один из подходов, имеющих право на жизнь. В определенной нише. Тема поднималась не для того, чтобы обсудить надо его использовать или не надо - это вопрос личный, а для того, чтобы определить ограничения популярных ORM. Если у вас - в тех проектах, где заняты вы - проблемы с ORM, то это не значит, что такие же проблемы возникают у всех. Мне странно, что приходится объяснять вещи такого рода взрослым людям.

-~{}~ 29.09.06 10:07:

... Обратите внимание, кстати, на то, что написано в статье

There is no silver bullet, наконец.

вы же говорите так, будто у вас в кармане целый пулемет, снаряженный ими.

 

[atv]

1) богатство реляционных операций несоизмеримо больше возможностей ORM. Какие есть номера категории не ниже 4-х звезд на южном побережье испании не дороже 50$ в день, с видом на море и хорошим пляжем, и чтобы в меню местного ресторана была отменная вегетарианская кухня.

Всё это - суть применение фильтров к связанным спискам.

$rooms->setFilter('category = 4 and price <= 50 and place = "с видом на море и хорошим пляжем" ');

$countries->setFilter('name = "испания"');

$restaurants->setFilter('kitchen = "вегетарианская"');

Никто из ORM-щиков не хочет поэксперементировать с подходом, который я предложил http://phpclub.ru/talk/showthread.php?s=&threadid=91066&perpage=20&pagenumber=5

 

[fisher]

>>Оптимизация алгоритмов - да, серьезно. Представьте себе.
>>Естественно, при более сложной задаче, чем "выбрать записи с 1 по 10".
90% тупки вашей системы - база. Правильная работа с базой - святая святых любого программиста. Чтобы правиьлно работать с базой надо знать SQL и понимать, почему математически эквивалентный набор одних SQL приводит в к одному результату по скорости, а другой к другому. ORM - в большинстве случаев прослойка, которая строит SQL. Те, кто ее строят - почти никогда не дают вам нормальной возможность влезть туда вам самим. Сможете ли вы сделать на ORM элементарный запрос вида set counter = counter+1, updated=updated чтобы запрос выполнился _СИЛЬНО_ быстрее потому что updated это автоматический timestamp, но по updated есть индекс, и в данном случаем вам не нужно менять время?

Посмотрите разницу между plain sql и pl/sql из приведенной ссылки, наконец.

>>А вы понимаете, что увеличение времени разработки на 300%
>>и стоимости поддержки на 50% ради увеличения производительности
>>10% может этот выигрыш съесть?
понимаю, за исключением того, что цифры Ваши - с потолка. гибкость - не есть достоинство ORM. переписать SQL-запрос, понять по одному лишь запросу модель, разбить один запрос на несколько - легче когда есть plain SQL, чем разбираться в ORM-based коде.

>>Вообще, fisher, Фанат из вас хреновый
и слава Богу Фанат может быть только один, но Фанат санитарит тех, которые совсем уже. А вы-то не такие. Ну если обидел чем-то - извините.

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

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

>>Уже писался. Раньше в теме.
я видел этот код. предстаьте себе, что кто-то его написал год назад. за год у Вас выросла нагрузка, вам надо затюнить приложение, и скорее где-то просто переписать запросы, а где-то и вовсе изменить архитектуру. Программист, написавший этот код - уволился. Допустим, там не один запрос, а десять. вот как только по этому коду понять "модель"? А теперь посмотрите на SQL который привел Alexandre. Вы действительно не считаете, что SQL понятнее?

>>.. Обратите внимание, кстати, на то, что написано в статье
bkonst, если Вы ещё не поняли - эту "статью" писал я, как и весь текст на этом сайте. года три назад. я знаю, что там написано и целиком и полностью разделяю

 

[atv]

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

Что есть, то есть. Обсуждение постоянно скатывается от аргументов к личным перепалкам.

 

[whirlwind]

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

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


Вот такие фразочки

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

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

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

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

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

-~{}~ 29.09.06 12:17:

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

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

 

[Raziel[SD]]

Поддержка "ORM-кода" кода настоящий ад, к сожалению имеется немалый опыт.

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

 

[fisher]

2whirlwind
к сожалению, Вы не ответили ни на один вопрос по существу.

 

[atv]

ORM = данные + логика
ORM != данные
ORM != логика

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

 

[whirlwind]

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

Вот это

ORM выражения не читабельны

мне абсолютно не понятно. Что такое ORM выражения?

-~{}~ 29.09.06 12:36:

Если вручную заполнять объекты бизнес логики данными, а потом вручную выгружать данные обратно в БД - это будет ORM, или нет?

Я думаю нет. Потому что Relation Mapping подразумевает некоторую автоматизацию работы со связанными объектами.