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

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

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

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

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

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

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

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

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

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

Для получения дополнительной информации поищите в Интернете такие вещи, как "Object-relational impedance mismatch"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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