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

[Raziel[SD]]

whirlwind вот эти конструкции:

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

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

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

красиво и удобно только в теории.

 

[fisher]

>>до сих пор противники ORM не спускались до конкретных примеров
с ума посходили.
ещё раз, смотрите выше - элементарный запрос
set counter=сuonter+1, updated=updated where id = 5
напишите ORM-код.

ещё вопросы
- как сложно повлиять на конечный SQL в вашей ORM? поддердживает ли ваша ORM игры с leftmost написанием атрибутов в WHERE? поддерживает ли ваш ORM хинты СУБД? select /* use index blabla */ если не в курсе.
- поддерживает ли вас ORM bind паратеров чтобы база единожды компилила SQL-выражения
- в полной ри мере поддерживает ваша ORM sql-функции для данной реализации базы (текущее время, rowid, операции над строками и тд)? у всех баз они разные.

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

 

[bkonst]

Автор оригинала: fisher

90% тупки вашей системы - база. Правильная работа с базой - святая святых любого программиста. Чтобы правиьлно работать с базой надо знать SQL и понимать, почему математически эквивалентный набор одних SQL приводит в к одному результату по скорости, а другой к другому.

Отлично. Вопрос-таки состоит в том, что ORM генерирует неэффективный SQL?

Сможете ли вы сделать на ORM элементарный запрос вида set counter = counter+1, updated=updated чтобы запрос выполнился _СИЛЬНО_ быстрее потому что updated это автоматический timestamp, но по updated есть индекс, и в данном случаем вам не нужно менять время?

На какой ORM? На существующих (тех, по крайней мере, что я рассматривал) - нет. Там даже отбор по связанным объектам проблематично сделать (не говоря уж о применении к связанным объектам агрегатных функций), а это ограничение по функциональности, приводящее к тому, что те вычисления, что должны выполняться в базе, проделываются на стороне PHP. На "идеальной" - да. Благо в существующем прототипе я уже могу пометить атрибут модели как 'searchable', 'private' или 'internal' и получать в зависимости от этого SQL, более-менее разумно использующий индексы. Понимаете, вся оптимизация запросов подчиняется фиксированному - и не такому уж большому - набору правил, которые не так сложно реализовать в конкретном драйвере. Это не искусство, это рутина, которой должна заниматься машина.

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

Условий тестирования нет (битая ссылка на оригинал статьи). Без этого толку в цифрах нет.

понимаю, за исключением того, что цифры Ваши - с потолка.

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

гибкость - не есть достоинство ORM.

В некотором смысле вы правы. Само по себе O-R mapping ничего не дает. Однако с его помощью многие задачи можно автоматизировать. В идеале - описать модель и автоматически получить схему данных на реляционных табличках, код, поддерживающий целостность, код, проводящий валидацию, формы редактирования с контролем ошибок, скрипты миграции между версиями схемы данных и многое-многое другое. ORM в этой задаче - не самоцель, а лишь инструмент, позволяющий совместить объектную модель, которая более удобна для человека, с реляционной, которая более удобна для хранения данных. Составная часть. Вот такая система - гибкая.

переписать SQL-запрос, понять по одному лишь запросу модель, разбить один запрос на несколько - легче когда есть plain SQL, чем разбираться в ORM-based коде.

Ну, во-первых, в ORM-based коде не должно быть SQL-запросов - это признак того, что в коде-спагетти мешают несколько подходов. Так что "переписать SQL-запрос" отпадает. "понять по одному лишь запросу" модель - задача, откровенно говоря, довольно странная; пресловутый ORM-based код вообще должен на 99% состоять из описания модели. Если возникает задача "понять модель" - это плохая, негодная ORM. По поводу "разбить один запрос на несколько" -

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

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

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

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

Вперед. Приведенный код - фактически построение синтаксического дерева описания запроса вручную. Если очень хочется, его можно заменить на некий Object Query Language. Интерес представляет не то, что-де "мы выкинули SQL" (меняя шило на мыло), а то, что критерии запроса могут формироваться автоматически и то, что детали реализации (например, таблицы ассоциаций) скрыты. См. например второй пример Alexandre.

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

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

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

Модель описывается описанием модели (это не объявление класса), а не запросами. Честно. Или мы говорим о разных вещах. По поводу "переписать запросы/изменить архитектуру". Изменение архитектуры (в нормальном варианте развития событий, а не в том, где ORM притянута за уши) сведется к изменению описания модели и перегенерации кода. Как пример могу предложить изменить в модели связь 1:N на связь N:M. Хорошая ORM вообще скроет тот факт, что изменения были. SQL запросы придется основательно перелопачивать.

Однако, хотелось бы получить развитие темы "переписывания запросов". Это будет полезно и любопытно. С чем связано переписывание запросов? Изменение модели? Связей? Оптимизация, основывающаяся на набравшейся статистике?

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

Естественно, не понял, так как статья написана гораздо мягче. Или у вас сегодня приступ плохого настроения. Или хреново получается "охладить пыл". Как сказано в статье:

кое-что из этого списка(за исключением п.1) скорее не принципиальные минусы, а «сложности»

Любое изменение сложившегося порядка вызывает "сложности". ORM - не исключение.

-~{}~ 29.09.06 12:54:

Raziel[SD]

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

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

...Кому-то и LISP нечитабелен.

 

[whirlwind]

ещё раз, смотрите выше - элементарный запрос
set counter=сuonter+1, updated=updated where id = 5
напишите ORM-код.

Что Вы мне доказываете этим примером, что вручную Вы напишете запрос, который будет работать быстрее? Я ни капли не сомневаюсь.

Я подчеркиваю, не рассмотрение абстрактных запросов, а решение задач

-~{}~ 29.09.06 12:59:

ещё вопросы
- как сложно повлиять на конечный SQL в вашей ORM? поддердживает ли ваша ORM игры с leftmost написанием атрибутов в WHERE? поддерживает ли ваш ORM хинты СУБД? select /* use index blabla */ если не в курсе.
- поддерживает ли вас ORM bind паратеров чтобы база единожды компилила SQL-выражения
- в полной ри мере поддерживает ваша ORM sql-функции для данной реализации базы (текущее время, rowid, операции над строками и тд)? у всех баз они разные.

На все эти вопросы отвечает заготовка тех. спецификации, которую я все никак не допишу.

Модель устойчивых объектов. Техническая спецификация.

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

================================================================================

1. Что нам нужно от этой системы?

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

1.2 Мы хотим получить простой интерфейс для работы с устойчивыми объектами -
экземплярами классов, время жизни которых не ограничено временем работы
программы, но регулируется механизмами бизнес-логики.

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

1.4 Мы очень хотим получать меньше головной боли от "разности стандартов". Наши
программы должны работать с основными (распространенными) базами данных с
наименьшим сопротивлением при смене источника данных. Это так же означает, что
модель стремится свести "разность стандартов" в сторону уменьшения, а
непосредственный контакт программиста с тонкостями работы источников данных
должен происходить как можно реже (вот как только приспичит перенести какой
нибудь поиск с PostreSQL на SQLite, вот тут то сразу и начинается борьба
"стандартов").

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

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

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


2. Чего мы не хотим?

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

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

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

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

2.5 Мы не хотим быть привязаными к системе. Источники данных должны быть из
категории "легкодоступных".

 

[fisher]

2whirlwind:

>>Что Вы мне доказываете этим примером, что вручную Вы напишете запрос,
>>который будет работать быстрее? Я ни капли не сомневаюсь.
нет, я тоже в этом не сомневаюсь. мне интетренсо, можно ли вообще у вас написать такой запрос. если можно, то как это будет выглядеть и будет оли понятным.

я кстати ещё Вам вопросов назадавал

 

[svetasmirnova]

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

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

Кстати, а почему нет?

 

[atv]

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

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

Значит уравнение надо переписать так:
ORM = данные + логика + взаимосвязи.

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

вот эти конструкции красиво и удобно только в теории.

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

Вот если бы с базой можно было работать через специализированный API, а не через SQL, то проблема отображения значительно упростилась бы.

 

[whirlwind]

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

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

PS. Я к тому, что в 1С применяется смешанный подход. Там оптимизация выполняется только где она реально нужна.

Кстати, а почему нет?

Ну потому что ORM сам реализует $this->setRaw(RecordSet $rs);
Можно и в ручную, только весь цимус пропадает.

я кстати ещё Вам вопросов назадавал

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

 

[Raziel[SD]]

atv

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

1. я специально умолчал в своем посте про скорость.
2. я не понимаю, мы говорим о неком абстрактном "перпентуум мобиле" или о существующих реализациях ? я говорил о существующих реализациях.

Об этом я и говорил, что полноценная ORM должна выполнять пловину работы БД

зачем дублировать функционал БД? Мне казалось, что она должна дополнять функционал БД.

 

[whirlwind]

>Они пытаются отображать только данные, а нужно отображать ещё и взаимосвязи.

2atv: по моему Вы плохо знакомы с предметом обсуждения. Сами связи не имеют смысла. Нам нужны связанные объекты. Получение связанных объектов умеет любая реализация ORM, иначе ее ORM назвать нельзя. Всего остального может не быть, но работа со связанными объектами это так сказать основной смысл.

 

[fisher]

2 whirlwind

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

2bkonst:
>>состоит в том, что ORM генерирует неэффективный SQL
в первую очередь. сама идея делать OR отображение с точки зрения "теории" довольно красивая, у всех реализаций свои заморочки но дело щас даже не в них.

>>С чем связано переписывание запросов? Изменение модели?
>>Связей? Оптимизация, основывающаяся на набравшейся статистике?
а и то и другое - и оптимизация, и изменение модели.

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

>>Вы так легко оперируете цифрами безотносительно конкретной
>>задачи, что я прямо-таки позавидовал.
пардон, единственная цифра которую я написал была 10% по скорости и в каком контексте - что 10% это может быть очень много. чему завидовать?

>>Условий тестирования нет (битая ссылка на оригинал статьи).
>> Без этого толку в цифрах нет.
блин, действительно битые, статья старая но на те тесты кстати много кто ссылался, попробуйте набрать oracle_mysql_performance в гугле. я не могу сходу найти оригинал, а жаль. впрочем спросите у любого ораклиста, pl/sql процедуры сильно ускоряют дело, эти тесты вряд ли фейк, любой их может провести сам.

короче, в чем проблема имхо - резюме. вы не хотите признать, что качество разработки проекта с РСУБД в первую очередь есть качество реляционной модели и максимально эффективное использование ресурсов базы. и это корень всех проблем с ORM имхо. понимаете, акценты смещены куда-то во сторону программирования ради программирования. разве у вас самих нет такого ощущения?

 

[bkonst]

fisher
В целом, понял вашу точку зрения.

- как сложно повлиять на конечный SQL в вашей ORM? поддердживает ли ваша ORM игры с leftmost написанием атрибутов в WHERE? поддерживает ли ваш ORM хинты СУБД? select /* use index blabla */ если не в курсе.

В "абстрактный генератор запросов" aka "perpetuum mobile"-то всё можно воткнуть.

Отклоняясь от темы: что вы понимаете под "игры с leftmost написанием атрибутов в WHERE"?

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

Это, по-моему, даже существующие реализации поддерживают. Хотя могу ошибаться.

- в полной ри мере поддерживает ваша ORM sql-функции для данной реализации базы (текущее время, rowid, операции над строками и тд)? у всех баз они разные.

С моей точки зрения, sql-функции нужны для реализации хранимых процедур и триггеров; зачем выполнять такую обработку на стороне базы?

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

Ок. Смотрим ранее приведенный пример:
[sql]
SELECT c.shortname, o.objects_id, o.shortname, o.rus_name, v.rus_value, v.selects_vals_id
FROM emhe_catalog c
LEFT JOIN emhe_catalog_objects co ON co.emhe_catalog_id = c.emhe_catalog_id
LEFT JOIN objects o ON o.objects_id = co.objects_id
LEFT JOIN select_object_vals vo ON vo.objects_id = o.objects_id
LEFT JOIN selects_vals v ON vo.selects_vals_id = v.selects_vals_id
WHERE c.shortname = '2006clubs' AND v.selects_vals_id = 202
LIMIT 20 ;
[/sql]
и

$filter = new ORMFilterCompositeAND();
$filter->add_filter(new ORMFilterBoundObject('Val', new ORMFilterPrimaryKey(202));
$filter->add_filter(new ORMFilterBoundObject('Catalog', new ORMFilterEquality('shortname', '2006clubs'));
$items = $manager->itemsFiltered($filter, 0, 20);

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

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

И что, прямо-таки на любой задаче эти 10% достигаются? И без дополнительных затрат? И всегда оправдывают эти затраты?

блин, действительно битые, статья старая но на те тесты кстати много кто ссылался, попробуйте набрать oracle_mysql_performance в гугле. я не могу сходу найти оригинал, а жаль. впрочем спросите у любого ораклиста, pl/sql процедуры сильно ускоряют дело

Похоже, ссылка была как раз на оригинал.

короче, в чем проблема имхо [бла-бла пропущено]

А вот это, пожалуйста, оставьте. Если мне нужен диагноз, я пойду к врачу. Заметьте, что у меня нет проблем с ORM. Проблемы у вас. И меня интересует, почему.

... да, кстати, оптимизация ради оптимизации не меньшая глупость, чем ORM ради ORM.

Raziel[SD]

2. я не понимаю, мы говорим о неком абстрактном "перпентуум мобиле" или о существующих реализациях ? я говорил о существующих реализациях.

Я, допустим, говорю об абстрактном. Об идеологии и принципах ORM. Чтобы знать, с чем сталкивались другие, что им хочется, проблемы с которыми сталкивались. Реализации, которые я видел, моим чаяниям не отвечают совершенно.

 

[fisher]

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

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

>>А вот это, пожалуйста, оставьте. Если мне нужен диагноз, я пойду к
>>врачу. Заметьте, что у меня нет проблем с ORM. Проблемы у вас.
>>И меня интересует, почему
ну хватит, ладно. проблемы у меня, как же я вам достаточно подробно объяснил в чем проблема ORM, принципиальная, нормальным образом неразрешимая и при этом очень критичная для бизнеса. я ж про забивание гвоздей микроскопом не просто так сказал. а вы это проблемой не считаете. ну что ж, ваше право.

>>Положа руку на сердце, неужели первый пример, изобилующий ссылками на вспомогательные таблицы, дает нормальную возможность разобраться в модели?
>>Он что, более читабелен? Более привычен, да.
погодите, вы что-то упустили. там 4 джойна - а у вас они где? к тому же, положа руку на сердце, вы ведь взяли очень простой запрос

 

[bkonst]

ну вы явно передергиваете.

Данифига. Я пытаюсь объяснить: не факт, что стоимость владения уменьшится от того, что приложение будет вусмерть заоптимизировано. Хотя бы потому, что:

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

ex: стоимость адаптации приложения к изменившимся требованиям. На этом тему о TCO и закроем.

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

Это про вы про генерацию нормальных SQL-запросов или я что-то упустил?

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

Ой дарадибога. Джойны скрыты за ORMFilterBoundObject, который позволяет проводить отбор по связанным объектам, используя описание модели. Там же две таблички ассоциаций в запросе участвуют... Неужели структура модели из запроса не видна?

Чем сложнее запрос (больше связей, особенно связей N:M), тем лучше будет выглядеть ORM-код по сравнению с SQL за счет скрытия деталей. Понятно, отбор по одной табличке будет выглядеть более громоздким.

 

[fisher]

2bkonst

>>Это про вы про генерацию нормальных SQL-запросов
>>или я что-то упустил?
проблема эффективного использования базы. сюда же и SQL, и триггеры, и хранимые.

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

>>Джойны скрыты за ORMFilterBoundObject, который позволяет
>>проводить отбор по связанным объектам, используя описание модели
а можно поподробнее плз. вообще, давайте вот вы же хотели на практике, да.

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

есть туристические маршруты(entity#1), по разным странам(entity#2). маршруты принадлежат разным компаниям(entity#3). каждый маршрут состоит из "точек" ((entity#4, m:m), проходит через разные города(entity#5), и где-то просто посещение достопримечательности(entity#6), где-то есть обед, а где-то ужин + ночевка. мне нужно
1) найти все компании, которые возят народ с ночевкой в барселоне (у кого-то там отель и он хочет продавать места в отеле оптом именно этим компаниям)
2) найти в каждой стране по 5 наиболее популярных достопримечательностей, через которые проходит больше всего маршрутов. задание со звездочкой. имея дополнительную информацию о частоте поездок и среднем размере группы в поездке найти в каждой стране 5 наиболее посещаемых достопримечательностей (у кого-то много денег и он гадает, где строить или покупать отель). почему в каджой стране - потому что есть ещё такие показатели как стоимость аренды, налоги и тд, и экспертная система все это должна учитывать.

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

 

[whirlwind]

>а можно поподробнее плз. вообще, давайте вот вы же хотели на практике, да.

будет Вам поподробнее, уже скоро, потерпите. И бизнес Ваш туристический разрулим.

 

[bkonst]

fisher
Спасибо за интересный пример, вечерком подумаю.

 

[zerkms]

товарищи, довольно, все уже поняли что у вас у всех как минимум до пола...

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

ps: а топик в очередной раз показал, что люди очень тяжело и редко меняют своё мнение (основанное на своём немалом опыте), на мнение других (основанное также на немалом опыте)

 

[StUV]

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

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

 

[atv]

Об этом я и говорил, что полноценная ORM должна выполнять пловину работы БД

зачем дублировать функционал БД? Мне казалось, что она должна дополнять функционал БД.

Я неточно выразился. Правильнее сказать не должна, а приходиться выполнять половину работы. И сказал я это к тому, что будь у нас другой способ работы с БД, вместо SQL, то эту половину работы не пришлось бы реализовывать в ORM.

В принципе, изминения в СУБД нужны незначительные - именованные курсоры (в некоторых уже есть), возможность применения фильтров (наподобие ORM API) и несколько событий.

Может кактить камень в сторону СУБД, чтобы расширили свой API, если не хотят быть вытесненными объектными БД.

whirlwind

Сами связи не имеют смысла. Нам нужны связанные объекты.

Вот и как Вас понимать??? Вообще, я уже отчаялся найти с Вами взаимопонимание. Если Вам непонятна моя мысль, уточните её, задайте наводящий вопрос. А Вы делаете ложные выводы и на их основе даёте ответ.

На последок вспоминается одна притча:
В посёлке жил мудрец, к которому приходили люди решать свои разногласия. Однажды приходит к нему человек и жалуется на своего соседа. Мудрец внимательно выслушал его и сказал, что тот абсолютно прав. Затем приходит к мудрецу тот самый сосед и тоже жалуется на первого соседа. Мудрец и его внимательно выслушал и сказал, что он абсолютно прав. Жена мудреца, ставшая свидетельницой этих разговоров сказала: "они рассказали тебе совершенно противоположные факты, а ты обоим сказал что они правы". На что мудрец ответил жене, что она абсолютно права.

Я не ставлю под сомнение опыт противников ORM. Он основан на практическом опыте. Но, являются ли недостатки ORM, недостатками самой идеи, или недостатками реализаций этой идеи. Именно это, я так понимаю, и хотел выяснить автор этой темы.

Я сам, поразмыслив какое-то время над проблемами ORM, изменил своё мнение о самой идее. Но и возможности реализовать её в рамках одного только SQL, не вижу. Как я уже сказал, неплохо было бы расширить API работы с БД, тогда и ORM могла бы получиться практичная.

Конечно же, это только рассуждения не подкреплённые практикой.