1. У нас старт проекта, модели данных толком нет, а то что есть поменяется 25 раз в процессе.
Целесообразно ли не заморачиваться на ней и использовать ORM? Пожалуй что да.
2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет (вообще ущербных "БД" полно), интернет завален постами о том как чуваки стали делать джойны в коде и стали супергероями.
Работа тупая, ORM справится легко, и дешевле
3. Куча таблиц в БД используется как справочные, к ним и джойнов-то нет, только FK.
К ним лепится простой DataGrid и этого более чем достаточно.
ORM тут зарулит тебя в хлам, потому что BindingList
4. Идем дальше. Возьми какой-нибудь девэкспресс.
Там на колонки гридов вагон разных фильтров, группировок, сортировок и выглядят они очень хорошо.
И внезапно выясняется что вевэкспресс вполне себе умеет транслировать эти фильтры в запросы к БД.
Любой нормальный программист на реализацию этого потратит человеко-месяцы.
T>При этом ты умеешь таблицы, схемы и запросы составлять непосредственно к/в СУБД? — зачем в этом случае нужен ORM.
Здорово(без шуток), в фетиш это только не надо превращать
Здравствуйте, rm822, Вы писали: R>1. У нас старт проекта, модели данных толком нет, а то что есть поменяется 25 раз в процессе. R>Целесообразно ли не заморачиваться на ней и использовать ORM? Пожалуй что да.
Тема не раскрыта.
R>2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет (вообще ущербных "БД" полно), интернет завален постами о том как чуваки стали делать джойны в коде и стали супергероями. R>Работа тупая, ORM справится легко, и дешевле
C MySQL работал очень мало, хоть он и занимает второе место в рейтинге СУБД. Ничего не могу сказать. Разве что удивиться, как он с таким косяком занял второе место?...
Если ORM — костыли для кривой СУБД — ок, вещь полезная, если поменять кривую СУБД нельзя.
R>3. Куча таблиц в БД используется как справочные, к ним и джойнов-то нет, только FK. R>К ним лепится простой DataGrid и этого более чем достаточно. R>ORM тут зарулит тебя в хлам, потому что BindingList
Тема не раскрыта.
R>4. Идем дальше. Возьми какой-нибудь девэкспресс.
Девэкспресс уважаю, дальше можно не писать. Но я не считают Девэкспресс ORM — ом. Разве что элементы ORM он содержит. Но, прежде всего, это UI.
R>Здорово(без шуток), в фетиш это только не надо превращать
Да не в фетише дело, а в том, где, в ответе на вопрос: для каких задачах ORM нужен?
Из твоего поста я понял, что ORM нужен не только для кривых программистов, но и для кривых СУБД.
Возможно.
А если СУБД нормальная и программист нормальный? — пока тема не раскрыта.
DevExpress, повторюсь, из другой темы.
С нетерпением жду ответа о готовности к "дуэли" от Danchik
Здравствуйте, rm822, Вы писали:
R>2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет
Вы пишете из 2000-го года? Можно я машину времени на минутку позаимствую?
R>3. Куча таблиц в БД используется как справочные, к ним и джойнов-то нет, только FK. R>К ним лепится простой DataGrid и этого более чем достаточно. R>ORM тут зарулит тебя в хлам, потому что BindingList R>4. Идем дальше. Возьми какой-нибудь девэкспресс.
Точно, 2000-й год.
Здравствуйте, Titus, Вы писали:
T>Мистер теоретег, вы в курсе, что тот же OleDB не поддерживает некоторые параметризованные select запросы для некоторых СУБД. Что это? — Незадокументированная фича, или ошибка — вопрос второй.
Предлагаете вообще не использовать фичи безопасности, если их "некоторые СУБД" не поддерживают?
T>Вопрос первый: как сделать так, чтобы программа, работавшая с одной СУБД работала бы также и с другой?
Здравствуйте, Cyberax, Вы писали:
R>>2.Не все БД одинаково полезны. MySQL джойны толком делать не умеет C>Вы пишете из 2000-го года? Можно я машину времени на минутку позаимствую?
Вне зависимости от того, есть ли на MySQL проблемы именно с джоинами, или нет, я бы никому не посоветовал ею пользоваться — лучше хотя-бы PGSQL взять, если нет ничего лучше. Хреновейшая оптимизация запросов, внезапно всплывающие ошибки — худшая СУБД из виденных мною (включая постгрю и sql lite).
(Впрочем, допускаю что могут существовать и худшие, но из популярных mysql (и его форки) на первом месте с конца по качеству)
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали: D>>>>Вызываю вас на дуель. Я считаю что linq2db строит супер запросы. Я писал трехэтажные квери, которые оптимизировались, как на меня, практически идеально.
T>>>Принимаю вызов. Нужна конкретная задача. Желательно, не очень большая. Желательно Database First.
D>>Я чесно не вижу кейса когда мы с чем то не свяжемся.
T>Да тут вопрос не в "свяжемся", а в скорости работы с/без ORM. T>Ты вызвал на дуэль, я выбираю "оружие" )) T>Я поставлю задачу, "основанную на реальных событиях".
T>Согласен? Готов? T>Хотя задача не сложная, п.3. может занимать до недели, потому что у меня куча других дел. Прошу сразу это понять и принять.
У меня как у архитектора этих дел завались, и еще linq2db пилить. Я тебе говорю одно, я решаю на linq2db сложнейшие задачи. Влоть до безшовного прикручивания security. Я даже больше скажу, для клиентов самплы SQL генерю через linq2db, мне так проще его написать, так как я могу запрос разложить на запчасти и проверить каждую чать отдельно, а не разбиратся в сложных сабкверях.
Если у тебя реальные события основаны на оптимизации праметризированных запросов — мы можем инлайнить параметры легко и непринужденно как для всего запроса так и для кусочков. У нас есть человек который бегает к нам с исью после втыков от DBA, вот он параметрами нам всю плешь проел
Я тебе дам реальную задачу где твоя самописная ORM усрется. Напиши мне ad-hoc репортинг. Так чтобы человек мог выбирать источники даных и засовывать их в Pivot Grid который имеет всевозможные фильтрации и этот грид смог спокойно вызывать Count, Min, Max, Sum вот по этому источнику.
Здравствуйте, Somescout, Вы писали:
C>>Вы пишете из 2000-го года? Можно я машину времени на минутку позаимствую? S>Вне зависимости от того, есть ли на MySQL проблемы именно с джоинами, или нет, я бы никому не посоветовал ею пользоваться — лучше хотя-бы PGSQL взять, если нет ничего лучше. Хреновейшая оптимизация запросов, внезапно всплывающие ошибки — худшая СУБД из виденных мною (включая постгрю и sql lite).
Я работал с MySQL достаточно много. Он заметно быстрее PSQL для многих целей и за годы отлажен достаточно сильно. Если у вас что-то отваливалось, то вы что-то делали не так.
PSQL намного приятнее, конечно, но MySQL вполне адекватен.
D>Я тебе дам реальную задачу где твоя самописная ORM усрется. Напиши мне ad-hoc репортинг. Так чтобы человек мог выбирать источники даных и засовывать их в Pivot Grid который имеет всевозможные фильтрации и этот грид смог спокойно вызывать Count, Min, Max, Sum вот по этому источнику.
Если мы говорим об ad-hoc репортинге/анализе, то его приходилось продавать/внедрять много раз.
Но мне никогда не приходилось голову изобретать bi инструментарий еще раз: Pentaho, BusinessObjects, QlikView etc… Excel, в конце концов (кстати, самый популярный BI инструмент).
В чем их недостатки перед твоим решением?
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Я тебе дам реальную задачу где твоя самописная ORM усрется. Напиши мне ad-hoc репортинг. Так чтобы человек мог выбирать источники даных и засовывать их в Pivot Grid который имеет всевозможные фильтрации и этот грид смог спокойно вызывать Count, Min, Max, Sum вот по этому источнику.
T>Если мы говорим об ad-hoc репортинге/анализе, то его приходилось продавать/внедрять много раз. T>Но мне никогда не приходилось голову изобретать bi инструментарий еще раз: Pentaho, BusinessObjects, QlikView etc… Excel, в конце концов (кстати, самый популярный BI инструмент). T>В чем их недостатки перед твоим решением?
А я спроектировал такое, недостатки у них были в цене и юзабилити. И в сложной схеме деплоймента конкретно того проекта.
Здравствуйте, Danchik, Вы писали:
D>А я спроектировал такое, недостатки у них были в цене и юзабилити. И в сложной схеме деплоймента конкретно того проекта.
А реальную задачу длительностью выполнения не больше часа на твоем ORM предложить можешь?
С полным ТЗ и исходными данными (при необходимости).
Здравствуйте, s_aa, Вы писали:
T>>1) Я ставлю задачу
_>К слову, а почему ты. Тогда уж третий кто-то, а вы оба решаете.
Да я не против, пусть кто-то другой предложит задачу (длительностью выполнения не более часа), при решении которой можно будет продемонстрировать преимущества ORM.
Здравствуйте, Titus, Вы писали:
T>Да я не против, пусть кто-то другой предложит задачу (длительностью выполнения не более часа), при решении которой можно будет продемонстрировать преимущества ORM.
Да легко. Нужно сделать глубокий рефакторинг имеющейся базы. В ОРМ всё понятно. А в чистом sql надо долго ходить и думать и вносить изменения руками в сотню мест.
Здравствуйте, Cyberax, Вы писали:
C>Я работал с MySQL достаточно много. Он заметно быстрее PSQL для многих целей и за годы отлажен достаточно сильно. Если у вас что-то отваливалось, то вы что-то делали не так.
что я не так делал?
С оптимизацией может сейчас и лучше, но когда видишь как тривиальная модификация запроса ускоряет его в разы (в то время как MSSQL выполняет одинаково быстро оба варианта) — желание использовать НедоSQL пропадает.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>А я спроектировал такое, недостатки у них были в цене и юзабилити. И в сложной схеме деплоймента конкретно того проекта.
T>А реальную задачу длительностью выполнения не больше часа на твоем ORM предложить можешь? T>С полным ТЗ и исходными данными (при необходимости).
Быстренько вставить миллион записей подойдет? MySql, SqLite не поддерживают быструю вставку, придется генерить простыни сиквелов. SQL Server поддерживает в полный рост. PostgreSQL частично. Вот linq2db это унифицирует и ты в основном не задумываешься что там за капотом.
Или еще лучше, взять миллион записей из одной базы PostgreSQL и кинуть их в MSSQL немножко изменив. Опять же можно тут говорить это же ETL и есть для этого тулзы. Но я это делаю за 5 минут написав код и запустив на 30 сек.
Здравствуйте, Ikemefula, Вы писали:
I> Да легко. Нужно сделать глубокий рефакторинг имеющейся базы. В ОРМ всё понятно. А в чистом sql надо долго ходить и думать и вносить изменения руками в сотню мест.
А я, пожалуй, соглашусь. Рефакторинг в парадигме Code First через ORM делать однозначно удобней и быстрее.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Я работал с MySQL достаточно много. Он заметно быстрее PSQL для многих целей и за годы отлажен достаточно сильно. Если у вас что-то отваливалось, то вы что-то делали не так.
S>Ну вот, например, тут http://rsdn.org/forum/db/6126852.1
что я не так делал? S>С оптимизацией может сейчас и лучше, но когда видишь как тривиальная модификация запроса ускоряет его в разы (в то время как MSSQL выполняет одинаково быстро оба варианта) — желание использовать НедоSQL пропадает.
Согласен запросы в MySQL надо оптимизировать, и ты будешь их оптимизировать.
И я очень рад что смог это спокойно победить на linq2db, в котором как ты запрос пишешь, так и получаешь.
Здравствуйте, Danchik, Вы писали:
D>Или еще лучше, взять миллион записей из одной базы PostgreSQL и кинуть их в MSSQL немножко изменив. Опять же можно тут говорить это же ETL и есть для этого тулзы. Но я это делаю за 5 минут написав код и запустив на 30 сек.
Пойдет. Только нужно уточнить аппаратную часть источника, приемника и сервера приложений.
Ну и сами базы данных нужны.
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, Danchik, Вы писали:
D>>Или еще лучше, взять миллион записей из одной базы PostgreSQL и кинуть их в MSSQL немножко изменив. Опять же можно тут говорить это же ETL и есть для этого тулзы. Но я это делаю за 5 минут написав код и запустив на 30 сек.
T>Пойдет. Только нужно уточнить аппаратную часть источника, приемника и сервера приложений. T>Ну и сами базы данных нужны.
Давайте я лучше сразу напишу как будет выглядеть код. Классы автоматом сгенерятся T4 шаблоном или простым описанием.
using (var sourceDB = new DataConnection(sourceConfig))
using (var destinationDB = new DataConnection(destinationConfig))
{
var source = sourceDb.GetTable<SourceTable>().Where(s => s.SomeDate < Sql.CurrentTimestamp);
var destination = sources.Select(s => new DestinationTable { Id = s.SomeId, Date = s.SomeDate ...});
destinationDB.BulkCopy(destination);
}
Здравствуйте, Titus, Вы писали:
T>Здравствуйте, takTak, Вы писали:
T>>а зачем тебе это надо знать?
T>Я так подумал, и понял, что изначально задал вопрос недостаточно точно, хотя, судя по ответам, большинством респондентов был правильно понят.
T>ORM (Object Relational Mapping, т.е. карта между объектами приложения и объектами БД), конечно же, я использовал и использую. Причем, в ярко выраженной форме я это начал делать довольно давно, после того как познакомился, осознал и принял на вооружение паттерн MVC. Буква M просто создана для этого мэппинга.
T>Но именно тогда, немного поиграв с Entity Framework, не осознал преимуществ и не принял на вооружение это ORM решение.
Вот досюда было верно.
А потом вы почему-то решили, что ORM==Entity Framework. Нет, EF унылый отстой не потому, что он ORM, а потому, что он отстой.
Просто его авторы не в курсе, зачем нужен ORM, поэтому они много лет копали тоннель не в ту сторону.
В результате, получилось так, что добавив в приложение EF, вы его, как правило, сделаете хуже. То есть более медленным, сложным, и хуже поддерживаемым, чем при использовании классического DAL.
Это не означает, что вообще все ORM такие. Приличные ORM гораздо больше усилий вкладывают в то, что от них требуется (порождение качественного SQL для динамически скомпонованных запросов; декомпозиция запросов; минимизация трафика между апп- и дб-сервером, оптимизация скорости чтения/записи), и не занимаются контрпродуктивной ерундой (lazy load, change tracking, неявные транзакции на контекстах).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
