Обсуждаем ORM

[Кувалдыч ТС]

вот этот запрос методами ORM не осуществить.

На уровне бизнес-логики никто не думает терминами запросов. Ибо заказчику пофигу какойто там непоняный скл... на таком языке он не разговаривает.  А если вам потребовался кривой запрос - так возникает вопрос - а с какого перепугу? И кто в этом виновать что он потребоался вдруг?

лишнее звено в виде ORM

Не лишнее, а дополнительное, с новыми возможностями и функциями. И зачастую с точки зрения разработчика единственным, ибо не надо тратить время и деньги н аразработку СУБД.

Что - то вроде

orm::factory->query('SELECT * FROM personnel')->as_obj?

Вобщето LINQ это не фича ОРМ, а самостоятельная фича. В дотнете любые объекты реализующие интерфейс IQueryable могут использоваться в LINQ.

[Кувалдыч ТС]

И профит только в том, что изучать его нет нужды.

Профит в том, что за каждую перестройку или изменение уже построеной дачи тебе не надо платить как за всю дачу плюс ее снос. Только за работы по изменению. При этом изменить можешь все. Включая фундамент. И в любое время, хоть через 20 лет. И при этом, при перестройки дачи тебе не надо оттуда съезжать.

[Paramedic]

http://andrey.moveax.ru/post/entity-framework-object-hierarchy-mapping

Читаем:

Режим "Таблица для иерархии (Table per hierarchy)"
Минусы

Добавление в таблицу служебного поля;
Уменьшение производительности при чтении записей конкретного типа из-за фильтрации;
Большой размер таблицы.


Режим "Таблица для каждого конкретного типа (Table per concrete type)"

Минусы

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

Режим "Таблица для каждого типа (Table per type)"

Минусы

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



Это что касается тормознутости.

Теперь что касается SQL.

"Решение проблемы с удалением записей

Добавить ON DELETE CASCADE"


Угу. Только каскадные воздействия это прерогатива чисто РСУБД, а не ORM. Т.е. получается смесь сладкого с зелёным. Более того, некоторый СУБД не поддерживают каскадных воздействий. В этом случае нужно писать триггеры. Опять как-то ORM не справилось с задачей.

[Paramedic]

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

В обычном походе всё абсолютно тоже самое. Не нужно ломать всю дачу, если можно что-то изменить. ORM здесь профита не даёт.

[Кувалдыч ТС]

Опять как-то ORM не справилось с задачей.

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

[Кувалдыч ТС]

всё абсолютно тоже самое

Вашими бы устами )))))))))))

ORM здесь профита не даёт.

В среднем проекте с "тупым" заказчиком как минимум в 3-4 раза удешевляет разработку и сроки )

[Paramedic]

Во первых, "ормщик" такой специальности нет.

Зато есть упёртые адепты.

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

Вот это и называется -- проектировать. А то, что рисуете на салфетках, это и есть ER-диаграмма. А окошки щёлкают, и кран крутиться, это CASE средства.

[OVA]

Чойта чем дальше тема, тем я прочнее убеждаюсь в том, что хвост не должен и не может рулить собакой.
Особенно "самостроящаяся дача" - ваще ужас!

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

Не смотря на обилие "конструкторов сайтов", к примеру, что-то не пользуются ими серьёзные конторы-то.
Зато каждая домохозяйка теперь может сделать себе собственный сайт!
Любые CASE-технологии, повторюсь, имеют свою нишу.

[Paramedic]

А если вам потребовался кривой запрос - так возникает вопрос - а с какого перепугу? И кто в этом виновать что он потребоался вдруг?

Запрос вполне себе прямой. Например: выбрать сотрудников, зарплата которых в течение последнего года не превышала среднюю за предыдущий год. Вот тут как-то ORM сдувается.

[Paramedic]

Одна проблема - тут не бывает одноуровневого приложения, ибо ОРМ это уже реализация второго уровня над БД.

Да ладно. Хотя бы ФреймВорк Kohana. Поставил, настроил настройки, и вперёд и с песнями. Всё в одном уровне.

[OVA]

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

Вы будете удивлены, но SQL задымывался как язык для менеджеров. Чтоб они сами могли строить выборки по произвольным комбинациям условий.
История повторяется. Менеджеры тупеют, требуются всё более навороченные инструменты для отупевшего персонала.
Где там тема про IT'шный шит-то?.. Самое время.

[Paramedic]

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

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

Что касается "ленивых запросов". Поясняю ещё раз. На извлечение ОДНОГО поля уходит ОДИН запрос к БД. Время доступа к удалённому серверу это самое медленное звено.

Допустим, полей 25. Получаем 26 (правило N+1) запросов вместо одного.

Вот и тормоза.

[Paramedic]

Просто она дала 3 инструмента на выбор.

Не инструменты, а способы. Способы давно известны, и ВСЕ способы приводят к тормозам и накладным расходам. Плюсов нет. Просто ORMщик наконец-то получил возможность наследования.

И каскадного удаления и джойна тут нет.

Каскадное удаление там есть: http://andrey.moveax.ru/post/entity-framework-object-hierarchy-mapping

Читай ближе к концу.

JOINы тоже есть. Ибо не бывает сущностей без связей.

[Paramedic]

Кувалдыч, ещё раз дам ссылку: http://citforum.ru/database/articles/vietnam/

Что интересно, ВСЕ три способа описаны в этой древней статье, так что ничего нового по твоей ссылке не написано. Читай раздел "Проблема объектно-табличного отображения"

Цитата:

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

[Paramedic]

В среднем проекте с "тупым" заказчиком как минимум в 3-4 раза удешевляет разработку и сроки

Уже обсуждали. Правда потом, когда в БД появляется первая сотня тысяч записей, всё это как-то перестаёт работать. Заказчику приходится тратиться на кластер серверов, и заказчик умнеет. Он начинает понимать, что лучше бы он на 1 500 000 рублей, потраченных на сервера, нанял путных разработчиков.