Здравствуйте, Danchik, Вы писали:

D>Можешь его использовать как простой маппер

Простой маппер отколупан и лежит в CodeJam. Тащить ради этого l2db не нужно.

D>Для некоторых он востребован как Linq over WCF, если вам надо спрятать базу с плохим security

По нынешним временам надо все таки odata использовать в качестве протокола.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Danchik, Вы писали:

D>>Можешь его использовать как простой маппер

НС>Простой маппер отколупан и лежит в CodeJam. Тащить ради этого l2db не нужно.

Я говорил про маппер из базы в обьекты.

D>>Для некоторых он востребован как Linq over WCF, если вам надо спрятать базу с плохим security

НС>По нынешним временам надо все таки odata использовать в качестве протокола.

Спасибо что напомнили. Только ODATA очень убог сравнивать даже нечего.

Здравствуйте, Danchik, Вы писали:

D>Спасибо что напомнили. Только ODATA очень убог сравнивать даже нечего.

Почему убог, есть джоины, проекции, фильтры, аггрегация

Здравствуйте, vorona, Вы писали:

V>Здравствуйте, Danchik, Вы писали:

D>>Спасибо что напомнили. Только ODATA очень убог сравнивать даже нечего.

V>Почему убог, есть джоины, проекции, фильтры, аггрегация

И все. Полноценный запрос не сделаешь. Вспомните что может SQL, а что попало в ODATA.

Здравствуйте, Danchik, Вы писали:

D>И все. Полноценный запрос не сделаешь. Вспомните что может SQL, а что попало в ODATA.

Из того что нельзя сделать в odata в голову приходят только оконные функции

Здравствуйте, vorona, Вы писали:

V>Здравствуйте, Danchik, Вы писали:

D>>И все. Полноценный запрос не сделаешь. Вспомните что может SQL, а что попало в ODATA.

V>Из того что нельзя сделать в odata в голову приходят только оконные функции

CTE, FULL JOIN... Ивините, я не хочу сейчас перебирать все ограничения, тоесть того что не попало в стандарт.

Я привел солюшин Linq over WCF, который упростит общение между своими серверами (не открытый endpoint). Также вы можете писать десктопные приложения где сервер базы данных нельзя выставлять наружу, что и понятно. Или мы учим ODATA и боримся с его граничениями или просто стартуем сервер с включенным Linq over WCF провайдером.

Здравствуйте, Danchik, Вы писали:

Рекурсивные запросы можно писать через $levels

Example 94: all employees with their manager, manager's manager, and manager's manager's manager

http://host/service/Employees?$expand=Model.Manager/DirectReports($levels=3)

Здравствуйте, Titus, Вы писали:

T>А если никто не заставляет тебя пользоваться ORM, и при этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.

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

Но смотрим дальше:

T>Если мы говорим об ad-hoc репортинге/анализе, то его приходилось продавать/внедрять много раз.
T>Но мне никогда не приходилось голову изобретать bi инструментарий еще раз: Pentaho, BusinessObjects, QlikView etc… Excel, в конце концов (кстати, самый популярный BI инструмент).

R>>4. Идем дальше. Возьми какой-нибудь девэкспресс.
T>Девэкспресс уважаю, дальше можно не писать.

Суть этих сообщений: берем готовый инструмент — пользуемся. Рукопашный код не нужен.
Суть ORM: берем готовый инструмент — пользуемся. Рукопашный код не нужен.

Не?


Странно, что никто не привел (или я пропустил, т. к. не все сообщения просмотрел) классический пример, где ORM заруливает (конкретно LINQ).

IQueryable<SomeEntity> query = db.SomeEntities;

if (someCondition1)
    query = query.Where(...);

if (someCondition2)
    query = query.Where(...);

Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак.
Делать ручную склейку текста sql — по сути, повторять часть ORM в своем коде.
Сделать динамический sql — пожертвовать производительностью.

Здравствуйте, koodeer, Вы писали:

K>Если умеешь, то да, можно без ORM. А если не умеешь?
В общем то ОРМ пишет запросы куда лучше чем программисты в 95 случаях из 100, а если уж говорить про долгосрочную перспективу с изменениями схемы данных...
Пример.
Жила была таблица Users к которой делали много разных запросов. И, как обычно писали 'select * from Users ....'. Через пару лет и полдесятка релизов в эту таблицу добавили поле 'Photo' и пользователи стали активно грузить фоточки в разрешении 4к. Что через довольно быстро привело к деградации производительности — туда сюда гонять мегабайтные картинки на каждый чих — это ж не 2 байта переслать. Для решения надо пройтись по всему солюшну и поменять 'select *' на 'select id, name,....'. Нигде не пропустить, подфиксать все тесты, в общем интересная и увлекательная работа, чреватая косяками и требующая полной регрессии(а может гдето закопипастили неправильно и запрос кривой вышел, к примеру запятую случайно упустили)
В случае ОРМ надо просто сделать отдельную модель для юзкейсов с фото. Старый функционал трогать не надо и он будет работать как надо — запросы строятся динамически и правильно.

Здравствуйте, koodeer, Вы писали:

[Skip]

K>Странно, что никто не привел (или я пропустил, т. к. не все сообщения просмотрел) классический пример, где ORM заруливает (конкретно LINQ).

[Skip]

K>Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак.
K>Делать ручную склейку текста sql — по сути, повторять часть ORM в своем коде.
K>Сделать динамический sql — пожертвовать производительностью.

Ох, ну это для меня очевидно, наверное потому и не подумал приводить.
Именно используя такие техники легко и непринужденно строится SQL запрос, что при склейке строк действительно мрак.
Потом если такую выборку или, как правило посложнее с групировками, засунуть в функцию, то можно на нее заджоиниться (чем вам не View) — query decomposition.

T>А если СУБД нормальная и программист нормальный? — пока тема не раскрыта.
Нечего тут раскрывать,
Есть те которые не умеют и не хотят, их большинство. Для них — тяжелые ОРМ
И есть те кто уже нахерачился, умеет и больше не хочет. Для них легкие ОРМ
И есть ты, который любит фигачить запросы самостоятельно. ОРМ чтобы ты страдал

Здравствуйте, itslave, Вы писали:

I>В общем то ОРМ пишет запросы куда лучше чем программисты в 95 случаях из 100, а если уж говорить про долгосрочную перспективу с изменениями схемы данных...

Есть примеры?

I>Пример.

Плохой пример. select * это моветон. Никто в своем уме этого не пишет. К тому же возникают вопросы к базе, даже если писать select *, будет передаваться дескриптор блоба, а не сами данные. Подгрузка всех данных это кстати типичная проблема ORM. Только не фоток, а просто больших строк, описаний там всяких. Оно вроде по отдельности немного, но в перспективе замедляет.

Здравствуйте, vsb, Вы писали:


vsb>Плохой пример. select * это моветон. Никто в своем уме этого не пишет.
Разве что в волшебной эльфии.
Но даже если перечислять поля, то любое изменение схемы базы неминуемо приводит к ручному переименованию полей по всем запросам, что во первых чревато опечатками и требует регрессии, во вторых — очень занятная и высокоинтеллектуальная работа.
В отличии от ОРМ где
а) можно в одном месте настроить мапинг
б) переименование полей обьектов во первых зачастую делается автоматически средой разработки, во вторых в случае чего — дает ошибки на стадии компиляции.

vsb>Подгрузка всех данных это кстати типичная проблема ORM. Только не фоток, а просто больших строк, описаний там всяких. Оно вроде по отдельности немного, но в перспективе замедляет.
Дык не надо фигню всякую добавлять в модель, и оно его подгружать не будет. Все просто.
Ну и чтобы 2 раза не вставать:
— программисты пишущие ОРМ знают SQL вообще и диалект для каждой конкретной базы гораздо лучше среднестатистического васи-кодера, который может просто, к примеру, забыть limit воткнуть в запрос
— динамическая компоновка запросов на linq в тысячи раз удобней, поддерживаемей и гибче чем строковые манипуляции для формирования sql
— мапинг с базы на обьекты(его как никрути придется делать в сколько нибудь сложной системе) выполненный на уровне ORM быстрее обычной инициации дата обьектов через присваивания полям значений
В общим raw SQL в продакшне не нужен в 95 случаях из 100

Здравствуйте, itslave, Вы писали:

I>Разве что в волшебной эльфии.

Ну это из разряда "функциями пользуются в волшебной эльфии, а у нас всё в main-е и это типа везде так". Есть определённые антипаттерны и select * один из них.

I>Но даже если перечислять поля, то любое изменение схемы базы неминуемо приводит к ручному переименованию полей по всем запросам, что во первых чревато опечатками и требует регрессии, во вторых — очень занятная и высокоинтеллектуальная работа.

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

I>а) можно в одном месте настроить мапинг

Маппинг можно и при использовании SQL настроить в одном месте, это вещи не связанные.

I>б) переименование полей обьектов во первых зачастую делается автоматически средой разработки, во вторых в случае чего — дает ошибки на стадии компиляции.

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

vsb>>Подгрузка всех данных это кстати типичная проблема ORM. Только не фоток, а просто больших строк, описаний там всяких. Оно вроде по отдельности немного, но в перспективе замедляет.
I>Дык не надо фигню всякую добавлять в модель, и оно его подгружать не будет. Все просто.

И что мешало не добавлять всякую фигню в случае с SQL?

I> — программисты пишущие ОРМ знают SQL вообще и диалект для каждой конкретной базы гораздо лучше среднестатистического васи-кодера, который может просто, к примеру, забыть limit воткнуть в запрос

ORM генерирует абсолютно простейшие SQL-запросы. Никаких знаний для ТАКИХ запросов не нужно. В этом собственно и есть одна из проблема ORM, эти запросы чересчур примитивные. Автоматически ORM лимит точно так же не втыкает, по крайней мере адекватный. Если тебе нужен лимит, тебе нужно это прописывать в HQL или в API, что ничем не отличается от SQL.

I> — динамическая компоновка запросов на linq в тысячи раз удобней, поддерживаемей и гибче чем строковые манипуляции для формирования sql

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

I> — мапинг с базы на обьекты(его как никрути придется делать в сколько нибудь сложной системе) выполненный на уровне ORM быстрее обычной инициации дата обьектов через присваивания полям значений

Чагой-то быстрей? Он на магии работает что ли? Точно так же setField вызывает.

I>В общим raw SQL в продакшне не нужен в 95 случаях из 100

Зависит от задач. На каких-то не нужен. На каких-то нужен.

Здравствуйте, vsb, Вы писали:

vsb>Ну это из разряда "функциями пользуются в волшебной эльфии, а у нас всё в main-е и это типа везде так". Есть определённые антипаттерны и select * один из них.
Я видел много разных больших проектов, из разных стран и контор, новых и с историей, думаю выборка достаточно репрезентативна.

vsb>При желании можно решить эту проблему. Например на каждый запрос писать простой юнит-тест, который просто делает prepare. Несовпадение с БД = упавший тест. В принципе при ручном написании запросов хотя бы простенький юнит-тест на каждый запрос это очень удобно. Впрочем как и в случае с ORM.
Это будет частичное решение проблемы. Да, от опечаток защитит, но Find/Replace копипастой по всему проекту вручную — это тупая ресурсоемкая работа, которая в случае ОРМ выполняется автоматически средой разработки за пару секунд.

vsb>Маппинг можно и при использовании SQL настроить в одном месте, это вещи не связанные.
Можно, но тогда это будет заявкой на свой, домашний мини орм. Затем он неизбежно(в смысле если проект не загнется) обрастет репозитаарием, UoW, примитивным linq провайдером... и все это будет кривее, сложнее и хуже чем нормальный ОРМ из коробки.

vsb>В ORM точно так же можно писать запросы с полями, которые точно так же будут падать в рантайме. Их, наверное, будет меньше, тут не поспоришь.
Их будет очень сильно меньше в нормальных ОРМ, они предоставляют возможность типизированно указывать имена колонок в аргументах, как то например в EF(который нормальный относительно): x.Include(x=> x.ID)

vsb>И что мешало не добавлять всякую фигню в случае с SQL?
Лень, невнимательность, человеческий фактор. Ведь на одну модель — десятки или сотни запросов, в которых надо правильно перечислить нужные поля.

vsb>ORM генерирует абсолютно простейшие SQL-запросы. Никаких знаний для ТАКИХ запросов не нужно. В этом собственно и есть одна из проблема ORM, эти запросы чересчур примитивные. Автоматически ORM лимит точно так же не втыкает, по крайней мере адекватный. Если тебе нужен лимит, тебе нужно это прописывать в HQL или в API, что ничем не отличается от SQL.
В LINQ запросы можно генерировать динамически и прописав один раз в нужном месте

query = query.Take(25)

можно эту проблему порешать. В случае же с SQL такое реализовать нормально достаточно сложно.
Кстате про простейшие запросы — улыбнул.

vsb>Нет никаких проблем с динамической компоновкой запросов на SQL. На ORM он может и удобней, но толку от этого удобства нет, со строками работать не сложней.
Есть, типизированный билдер запросов в сотни раз удобней конкатенации строк, в которой нет ни проверок времени компиляции, запятые правильно втыкать и тд и тп.

vsb>Чагой-то быстрей? Он на магии работает что ли? Точно так же setField вызывает.
В каких про примитивных — возможно.

vsb>Зависит от задач. На каких-то не нужен. На каких-то нужен.
ну да, иногда приходится писать ручками. Но очень редко.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, itslave, Вы писали:

vsb>ORM генерирует абсолютно простейшие SQL-запросы. Никаких знаний для ТАКИХ запросов не нужно. В этом собственно и есть одна из проблема ORM, эти запросы чересчур примитивные. Автоматически ORM лимит точно так же не втыкает, по крайней мере адекватный. Если тебе нужен лимит, тебе нужно это прописывать в HQL или в API, что ничем не отличается от SQL.

Тут печальный случай, вы из мира Java. Я честно не увидел в Java хоть что-то приблизительное, по сравнению с .NET фреймворками подерживающих LINQ. JOOQ, все равно не то.

I>> — динамическая компоновка запросов на linq в тысячи раз удобней, поддерживаемей и гибче чем строковые манипуляции для формирования sql

vsb>Нет никаких проблем с динамической компоновкой запросов на SQL. На ORM он может и удобней, но толку от этого удобства нет, со строками работать не сложней.

Вот когда вам ORM соптимизирует запрос, сам, вот тогда вы поймете что склейка строк это прошлое.

I>> — мапинг с базы на обьекты(его как никрути придется делать в сколько нибудь сложной системе) выполненный на уровне ORM быстрее обычной инициации дата обьектов через присваивания полям значений

vsb>Чагой-то быстрей? Он на магии работает что ли? Точно так же setField вызывает.

Опять же вы из мира Java, в котором нет динамической кодогенерации налету. В .NET мапперы генерятся настолько высокопроизводительные, как будто вы написали код руками, а иногда они и быстрее ручного кода.

I>>В общим raw SQL в продакшне не нужен в 95 случаях из 100

vsb>Зависит от задач. На каких-то не нужен. На каких-то нужен.

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

Здравствуйте, koodeer, Вы писали:

T>>Девэкспресс уважаю, дальше можно не писать.

K>Суть этих сообщений: берем готовый инструмент — пользуемся. Рукопашный код не нужен.
K>Суть ORM: берем готовый инструмент — пользуемся. Рукопашный код не нужен.

K>Не?

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



K>Странно, что никто не привел (или я пропустил, т. к. не все сообщения просмотрел) классический пример, где ORM заруливает (конкретно LINQ).
K>

K>IQueryable<SomeEntity> query = db.SomeEntities;

K>if (someCondition1)
K>    query = query.Where(...);

K>if (someCondition2)
K>    query = query.Where(...);
K>

K>Ручное написание sql при двух условиях потребует четырех вариантов кода. При трех условиях — восьми, при четырех — шестнадцати и т. д. Поддерживать такой sql — мрак.
Интересная арифметика. Давай я напишу, как это делается врукопашную.

string sqlWhere=GetWhere(conditionID);
string sql="select blablabla from x3 where " + sqlWhere;
PopulateMyDbContext(sql);

количество строчек кода=3 при любом количестве условий. Сами условия можно хранить и менять в администрируемой таблице.

K>Делать ручную склейку текста sql — по сути, повторять часть ORM в своем коде.
Да, я не против, главное — краткость.
K>Сделать динамический sql — пожертвовать производительностью.
что ты имеешь в виду?

Здравствуйте, itslave, Вы писали:

I>.... Через пару лет и полдесятка релизов в эту таблицу добавили поле 'Photo' и пользователи стали активно грузить фоточки в разрешении 4к. Что через довольно быстро привело к деградации
Передай тому, кто засунул фотку непосредственнов в таблицу Users, что он долбо.
Если очень хочется хранить блобы в БД, то для них нужно делать отдельную extention таблицу.

I>В случае ОРМ надо просто сделать отдельную модель для юзкейсов с фото.
Не спорю, ORM смягчает ущерб от действий ламеров, волею судеб, ставших программистами.

Здравствуйте, Titus, Вы писали:

T>Интересная арифметика. Давай я напишу, как это делается врукопашную.

string sqlWhere=GetWhere(conditionID);
string sql="select blablabla from x3 where " + sqlWhere;
PopulateMyDbContext(sql);

T>количество строчек кода=3 при любом количестве условий.

Например, задано условие: выбрать из таблицы всех с возрастом больше 42. В запрос должно добавиться where. Если этого условия нет, в запрос ничего не добавляется. Уже два варианта sql.
Задано словие выбрать всех с именем Bob. Еще два варианта sql. Перемножаем с первым условием: итого 4 варианта.
И так далее.
LINQ сгенерирует любой вариант на лету. Причём если условаия не заданы, то в итоговом sql вообще не будет where.

T> Сами условия можно хранить и менять в администрируемой таблице.

То есть их нужно писать, хранить, поддерживать. Нельзя на лету добавить новое условие.


K>>Сделать динамический sql — пожертвовать производительностью.
T>что ты имеешь в виду?

Имею в виду вот это.

Здравствуйте, koodeer, Вы писали:

K>Например, задано условие: выбрать из таблицы всех с возрастом больше 42. В запрос должно добавиться where. Если этого условия нет, в запрос ничего не добавляется. Уже два варианта sql.
как тебе такое Илон Маск:

... where true

K>Задано словие выбрать всех с именем Bob. Еще два варианта sql. Перемножаем с первым условием: итого 4 варианта.
Ты понял смысл трех строчек, что я написал?

T>> Сами условия можно хранить и менять в администрируемой таблице.
K>То есть их нужно писать, хранить, поддерживать. Нельзя на лету добавить новое условие.
Любые условия нужно написать и хранить, хоть в таблице, хоть в коде.
В моем варианте условия хранятся в таблице, чтобы их менять редактирование кода и компиляция не нужны.



K>>>Сделать динамический sql — пожертвовать производительностью.
T>>что ты имеешь в виду?
K>Имею в виду вот это.

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