ORM против традиционного запроса к базе данных, которые являются их полями?

Ответ 1

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

При использовании простого SQL бизнес-логика тесно связана с моделью db, а операции с базой данных и оптимизация зависят от бизнес-логики. Поскольку нет модели оо, вы не можете обойти все объекты. Я видел много приложений, которые передают первичные ключи и извлекают данные из базы данных на каждом слое снова и снова. Я видел приложения, которые обращаются к базе данных в циклах. И так далее. Проблема заключается в том, что, поскольку бизнес-логика уже почти не поддается обслуживанию, нет места для каких-либо оптимизаций. Часто, когда вы пытаетесь повторно использовать хотя бы часть своего кода, вы соглашаетесь с тем, что он не оптимизирован для каждого случая. Производительность ухудшается по дизайну.

ORM обычно не требует, чтобы бизнес-логика слишком заботилась о доступе к данным. В ORM реализованы некоторые оптимизации. Есть кеши и возможность для партий. Эта автоматическая (и динамическая) оптимизация не идеальна, но они отделяют от нее бизнес-логику. Например, если часть данных условно используется, она загружает ее, используя ленивую загрузку по запросу (ровно один раз). Вам не нужно ничего делать, чтобы это произошло.

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

Другим недостатком ORM является (фактически, не сам ORM, а тот факт, что вы будете работать с реляционной базой данных и объектной моделью), что команда должна быть сильной в обоих мирах, реляционная, а также как оо.

Вывод:

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

Ответ 2

ORM довольно старый, по крайней мере, в мире Java. Основные проблемы с ORM: - Объектно-ориентированная модель и реляционная модель совершенно разные. - SQL - это язык высокого уровня для доступа к данным, но любой язык OO, такой как С#, Java или Visual Basic.Net Для получения дополнительной информации выполните поиск в Интернете по таким вещам, как "Сопротивление объектно-реляционного импеданса"

В любом случае, хорошая структура ORM позволяет сэкономить на некотором кодеке котельной. Но вам все равно нужно знать знание SQL, как настроить хорошую базу данных SQL-данных. Начните с создания хорошего databasemodel с использованием SQL, затем основывайте свою OO-модель на этом (не наоборот)

Однако вышеизложенное выполняется только в том случае, если вам действительно нужно использовать базу данных SQL. Я рекомендую также смотреть на движение NoSQL. Там такие вещи, как Кассандра, Couch-db. Хотя google'ing для .net-решений я нашел этот вопрос stackoverflow: Какие решения NoSQL существуют для .NET?

Ответ 3

Я автор книги с текстом, указанным в вопросе.

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

Одна из проблем, которые я имею с обычным ORM - например, LINQ to SQL или Entity Framework - заключается в том, что он часто приводит к тому, что разработчики делают вызовы БД, когда они даже не понимают, что они это делают. Это, в свою очередь, является убийцей производительности и масштабируемости.

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

Другие жалобы, которые я имею о ORM, включают:

• Нет поддержки для пакетной обработки команд
• Поддержка нескольких наборов результатов
• Поддержка табличных параметров не поддерживается
• Нет поддержки для внутренних асинхронных вызовов (их исключение из фонового потока не учитывается)
• Поддержка SqlDependency и SqlCacheDependency является klunky, если/когда она работает вообще

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

Ответ 4

Этот сайт использует Linq-to-SQL, я считаю, и это "довольно" высокий трафик... Я думаю, что время, которое вы сохраняете от написания кода плиты котла для доступа/вставки/обновления простых элементов, неоценимо, но там всегда есть возможность отказаться от вызова SPROC, если у вас есть что-то более сложное, где вы знаете, что можете написать немного кричащего быстрого SQL напрямую.

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

Ответ 5

ORM намного старше, чем Java и .NET. Первый, о котором я знал, - TopLink для Smalltalk. Это идея, старая, как постоянные объекты.

Каждая инфраструктура "CRUD в Интернете", такая как Ruby on Rails, Grails, Django и т.д., использует ORM для сохранения, потому что все они предполагают, что вы начинаете с чистой модели объекта листа: никакой устаревшей схемы не беспокоиться. Вы начинаете с объектов, чтобы моделировать вашу проблему и генерировать настойчивость.

Он часто работает с устаревшими системами: схема долговечна, и вы можете иметь или не иметь объектов.

Поразительно, как быстро вы можете создать прототип и работать с фреймами "CRUD в Интернете", но я не вижу, чтобы они использовались для разработки корпоративных приложений в крупных корпорациях. Может быть, это предрассудок из списка Fortune 500.

Администраторы базы данных, которые, как я знаю, говорят мне, что им не нравится SQL, генерируемый ORM, потому что он часто неэффективен. Они все хотят, чтобы настроить его вручную.

Ответ 6

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

ORM не новы в .NET, LLBLGen существует уже давно, я использую их более 5 лет в .NET.

Я видел очень плохой код, написанный без ORM (эффективные SQL-запросы, плохие индексы, вложенные вызовы базы данных - ouch!) и плохой код, написанный с ORM. Я уверен, что внес вклад в некоторые из плохой код тоже:)

Я бы добавил, что ORM - это, как правило, мощный инструмент повышения производительности, который позволяет вам перестать беспокоиться о db-коде для большинства приложений и сосредоточиться на самом приложении. Когда вы начинаете писать сложный код (например, страницы отчетов или сложные пользовательские интерфейсы), вам нужно понять, что происходит под капотом - незнание может быть очень дорогостоящим. Но, используя их правильно, они очень мощные, и IMO не окажет негативного влияния на производительность ваших приложений. Я бы не был счастлив в проекте, который не использовал ORM.

Ответ 7

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

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

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

Из того, что я наблюдал, сохранение сложной схемы базы данных, когда дело доходит до масштабируемости, становится главной болью по мере роста сайта (вы добавляете поле, переназначаете ограничения, повторно отображаете внешние ключи... и т.д.). Мне было не совсем понятно, почему. Они не используют базу данных NOSQL, хотя они находятся в Postgres.

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

Ричард покрывает обе стороны монеты, поэтому я согласен с ним.

Что касается полей, я действительно не совсем понимаю контекст "полей", о которых вы спрашиваете.

Ответ 8

Как уже говорили другие, вы можете написать неэффективный ORM-код, и вы также можете написать неэффективный SQL.

Использование ORM не позволяет вам знать ваш SQL и понимать, как сближается запрос. Если вы можете оптимизировать SQL-запрос, вы обычно можете оптимизировать запрос ORM. Например, критерии спящего режима и запросы HQL позволяют вам контролировать, какие ассоциации объединяются для повышения производительности и избегать дополнительных операторов select. Знание того, как создать индекс для улучшения наиболее распространенного запроса, может привести к нарушению производительности вашего приложения.

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

Ответ 9

Никогда не получалось ничего, кроме боли и разочарования от пакетов ORM. Если бы я написал свой SQL так, как они автогенерируют его - да, я бы утверждал, что быстр, в то время как мой код будет медленным:-) Вы когда-нибудь видели SQL, созданный ORM? Едва ли PK-s, использует FK-s только для ошибочной интерпретации "наследования", и если он хочет делать подкачки, он выгружает весь набор записей на вас, а затем удаляет 90% его:-))) Затем он блокирует все в поле зрения так как он должен взять на себя нагрузку на записи, например, вернулся к 50-летней пакетной обработке IBM.

Некоторое время я думал, что самая большая проблема с ORM - это раскол (не имея стандарта в 50-е годы - каждый год разные API, pardon "model":-) и идеологизация (каждый продает вам большую философию - всегда лучше, чем все остальные, конечно:-) Тогда я понял, что это действительно полный дилетантство, что первопричиной беспорядка и всего остального является только следствие.

Тогда все это стало иметь смысл. ORM никогда не предназначалась для того, чтобы быть совершенным или надежным - этого даже не было в списке:-) Это была академическая, "концептуальная" игрушка с первого дня, утешительная премия для профессоров разозлила, что все их "реляционные" исследовательские работы в Prolog упал, когда IBM и Oracle начали продавать эту ужасную вещь SQL и зарабатывать доллар: -)

Ближе всего я пришел к выводу, что это LINQ, но только потому, что это возможно и довольно легко выгнать все "отслеживание", а использование - как уровень десериализации для нормального кода SQL. Затем я прочитал, как объект, управляющий соединением, может создавать спонтанные сбои, которые звучат как преждевременный GC, в то время как у него все еще были какие-то болтающиеся вещи. Никоим образом я не собирался рисковать своей шеей после этого - нет, а не голова: -)

Итак, позвольте мне составить список:

• Полностью неаккуратный код - не будет страдать от ошибок и бедных
  • Не собирается принимать взаимоблокировки с ORM в 10-100 раз больше "транзакций"
• Резкое сокращение возможностей - в наши дни SQL имеет огромную выразительную силу.
• Связывание вас с бахромой и неряшливым API (каждый ORM нацелен на захват вашей кодовой базы)
  • SQL-запросы очень переносимы, а знание SQL полностью переносимо.
• Мне все еще нужно знать SQL, чтобы все равно стереть беспорядок ORM.
• Для "доказательства концепции" я могу просто сериализовать файлы в двоичных или XML файлах
  • не намного медленнее, нулевые библиотеки ошибок и один XPath могут выбрать лучше в любом случае
  • Я действительно сделал веб-сайты с большим трафиком из файлов XML.
  • Если мне действительно нужен реальный граф, тогда я не использую DB - ничего реального для запроса
  • Я могу сериализовать blob и дамп в SQL как 3 строки кода
• Если кто-то утверждает, что он делает все это от БД до UI - держите свою кодовую базу заблокированной:-)
  • и создайте резервную копию своей платежной ведомости - вы поблагодарите меня за последнее: -)))
• Базы NoSQL более честны, чем ORM - "мы специализируемся на сохранении"
  • и имеют лучшее качество кода - не удивлены вообще

Это будет короткий список:-) Кстати, современные SQL-устройства в наши дни делают деревья и пространственное индексирование, не говоря уже о подкачке без единой записи. ORM-s на самом деле "решают" проблемы 10 лет назад и продвигают дилетантство. В связи с этим NoSQL, также известный как документ