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

Question

ORM - быстрорастущая модель, в которой есть как плюсы, так и минусы.Из Ultra-Fast ASP.NET Ричарда Киссига (http://www.amazon.com/Ultra-Fast-ASP-NET-Build-Ultra-Scalable-Server/dp/1430223839/ref=pd_bxgy_b_text_b):

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

Мои вопросы:

• Как вы прокомментируете идею Ричарда. Согласны ли вы с ним или нет? Если нет, расскажите, пожалуйста, почему.

• Какие поля лучше всего подходят для ORM и традиционныхзапрос к базе данных - другими словами, где вы должны использовать ORM и где вы должны использовать традиционный запрос к базе данных :), какой тип / размер ... oДля приложений вы, несомненно, должны выбрать ORM / традиционный запрос к базе данных

Заранее спасибо

Answer 1

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

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

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

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

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

Вывод:

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

Answer 2

ORM довольно старый, по крайней мере, в мире Java. Основные проблемы с ORM:

• Объектно-ориентированная модель и реляционная модель весьма различны.
• SQL - это язык высокого уровня для доступа к данным на основе реляционной алгебры, отличающийся от любого языка ОО, такого как C #, Java или Visual Basic.Net. Смешивая их, вы можете худший из двух миров вместо лучшего

Для получения дополнительной информации ищите в Интернете такие вещи, как «Несоответствие объектно-реляционного импеданса»

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

Однако вышеприведенное верно только в том случае, если вам действительно нужно использовать базу данных SQL. Я также рекомендую изучить движение NoSQL. Есть такие вещи, как Кассандра, Couch-DB. При поиске решений для .net я нашел вопрос о стеке: https://stackoverflow.com/questions/1777103/what-nosql-solutions-are-out-there-for-net

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

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

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

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

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