ORM по-прежнему "Вьетнам компьютерных наук"?

Question

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

Answer 1

Это все еще правда.

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

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

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

По этой причине RoR и шаблон ActiveRecord заслуженно заслужили репутацию боровов ресурса dbms. Оптимизированный дизайн ActiveRecord чаще всего является неоптимальным проектом SQL, поскольку он способствует декомпозиции операторов SQL.

Answer 2

Да.

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

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

Во всех программах существует компромисс между гибкостью и предположениями . Фреймворки (такие как Rails) пытаются решить проблему, будучи «самоуверенными». То есть они ограничивают гибкость как реляционных, так и объектно-ориентированных аспектов проблемы, делая предположения о том, как структурированы данные и какие операции вы можете выполнять с ними. Естественно, упрощение пространства задач также упрощает решение.

Кроме того, огорчает обнаружение, что структура ORM неполна, поэтому некоторые обычные операции в SQL не имеют решения в данном ORM. Это также является следствием «самоуверенных» рамок.

Answer 3

Многие компании Web 2.0 работают над магазинами с ключевыми ценностями. И все эти компании должны пройти через один и тот же мучительный процесс, чтобы заставить его работать.

Если ORM - это «вьетнамская компьютерная наука», то создание собственного хранилища значений ключей, вероятно, является «Ираком компьютерной науки»:

Answer 4

Я могу говорить только за мой опыт. Я использую DAL и DTO, и я все еще могу выполнять довольно сложные запросы (объединения и все), а также я могу прибегать к SP или к пользовательскому SQL, когда мне это нужно. Это сделало мою жизнь проще, мой код соответствовал и мои сроки были более достижимыми.

Answer 5

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

База данных обязательно низкого уровня; он хранит числа и строки по существу. Бизнес логика высокого уровня. Вот почему у нас есть абстракция.

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

Итак: не выбрасывайте ORM, но и не используйте его по умолчанию. Это инструмент, который решает определенные проблемы. Игнорировать это было бы невежественно, а всегда использовать это было бы высокомерно.

Answer 6

Джеффс ссылается на статью Тед Ньюардс . Если вы в деталях, то вам нужно посмотреть там:

1. оригинал - http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

2. продолжение - http://blogs.tedneward.com/post/thoughts-on-vietnam-commentary/

Из оригинальных баллов Теда у меня есть это:

• 1 был не прав (личность)
• 2 из них решены (Частичные объекты и N + 1)
• 2 являются дискуссионными (двойная схема / общая схема).

Отказ от ответственности: я являюсь автором Ebean ORM, поэтому я буду ссылаться на него для различных «решений» поднятых вопросов.

Оригинальные очки Теда (искаженные, потому что это действительно многословно):

1. Неполная проблема объекта.

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

• См. http://ebean -orm.github.io / docs / query /partalobjects

2. N + 1 (парадокс времени загрузки Теда)

Всегда решаемо. Должно быть записано как 1 + N / batchSize, но это более интересно, чем это (для каждого пути необходимо учитывать SQL-пейджинг, избегать sql декартовых произведений). Некоторые ORM, к сожалению, вносят правильный вклад в это, и это делает ORM в целом дурной славой. Некоторые ORM в порядке, пока вы не достигнете уровня сложности (например, OneToMany внутри OneToMany внутри OneToMany).

• См. http://ebean -orm.github.io / docs / query / nplus1

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

• См. http://ebean -orm.github.io / docs / query / autotune

Эта идея автоматической оптимизации запросов ORM возникла в Техасском университете (с использованием Hibernate). Он был включен в состав Ebean ORM в 2008 году, поэтому уже давно.

• См .: https://en.wikipedia.org/wiki/AutoFetch

3. Идентичность

Тед рассуждает о несоответствии идентичности и параллелизма. Эта точка неуместна, так как ORM (ну, все, кого я знаю) описывают этот аспект в точно в том же поместье, что и в предыдущих клиент-серверных инструментах, и, в частности, ORM предоставляют SNAPSHOT просмотр части базы данных для приложения. Здесь никогда не возникало проблем, но реализации ORM могли вступить в конфликт с чрезмерной зависимостью, например, от hashCode () / equals ().

4. Задача двойной схемы

Это спорно. Если организация позволяет, то ORM может предоставить сценарий DIFF / SQL для схемы, который выполняется FlywayDB / Liquibase и т. Д. Если организации не позволяют, это может быть проблемой до некоторой степени.

5. Рефакторинг БД / Общая схема

Это спорно. Люди разработки / нормализации БД будут утверждать, что дизайн БД должен перейти на 4NF, и это означает, что любой рефакторинг должен быть исключительно аддитивным (денормализация, добавление столбцов / таблиц) и не прерывать изменения. Люди, которые не верят в нормализацию, будут сходить с ума от беспокойства по поводу общей схемы.

Answer 7

ИМХО, монадические подходы, такие как Slick и Quill от Scala, в значительной степени обходят вышеупомянутое болото, предлагая более надежные решения для многих проблем Теда (также заслуживает упоминания JOOQ). Хотя они не идеальны, они определенно убивают проблемы N + 1 и Partial Object, в основном убивают проблему Identity и частично убивают проблему Dual Schema. Забудьте о неуклюжих и многословных запросах CriteriaBuilder (кто-нибудь читает «Выполнение в Царстве Существительных ???») , монадические для понимания Scala дают вам простой DSL, в котором можно писать критерии-запросы:

case class Person(id: Int, name: String, age: Int)
case class Contact(personId: Int, phone: String)

val query = for {
    p <- query[Person] if(p.id == 999)
    c <- query[Contact] if(c.personId == p.id)
  } yield {
    (p.name, c.phone)
  }

Этот тип синтаксиса остается нормальным даже для более сложных запросов, например Запрос приемлемого супруга Теда:

case class Person(name:String, spouse:Option[PersonId]) {
    isThisAnAccpetableSpouse(person:Person) {...}
}

val query = for {
    p1 <- people
    p2 <- people if (
        p1.spouse.isEmpty && p2.spouse.isEmpty 
        && p1.isThisAnAccpetableSpouse(p2)
        && p1.isThisAnAccpetableSpouse(p1))
} yield (p1, p2)

Все это get скомпилировано в один запрос SELECT и запущено для базы данных. Вставки, обновления и удаления аналогичны.

Answer 8

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

Я не думаю, что его пост принимал во внимание возможность самой платформы (в данном случае AcitveRecord / Rails) определить базу данных и объектную модель, которая, насколько я могу судить, заставляет проблему идти прочь.

Так как это противоположно первым двум ответам (в основном, что пост устарел), я чувствую, что я, вероятно, чего-то не понимаю; Если это так, пожалуйста, поправьте меня, а не просто проголосуйте за меня, потому что я думаю, что я упускаю важный момент.

Answer 9

Я думаю, что это так.

Я думаю, что последнее предложение наиболее интересное из всех: «Я склонен ошибаться на стороне базы данных как модели, потому что я думаю, что объекты переоценены». Java, C ++ и C #, безусловно, являются доминирующими языками, но функциональное программирование возвращается с F #, Scala и т. Д.