Где ORMs проваливаются?
Я часто слышу, что люди колотят ORMs за то, что он был негибок и "текучая абстракция", но Вы действительно не слышите, почему они проблематичны. При надлежащем использовании, каковы точно отказы ORMs? Я спрашиваю это, потому что я работаю над PHP orm, и я хотел бы за него решить проблемы, которые много других ORMs приводит к сбою в, такие как ленивая загрузка и отсутствие подзапросов.
Будьте конкретны со своими ответами. Покажите некоторый код или опишите схему базы данных, где ORM борется. Не имеет значения язык или ORM.
4 ответа
Одна из самых серьезных проблем, которые я заметил со всеми ORM, которые я использовал, - это обновление только нескольких полей без предварительного извлечения объекта.
Например, у меня есть объект Project, отображаемый в моей базе данных со следующими полями: Id, name, description, owning_user. Скажем, через ajax я хочу просто обновить поле описания. В большинстве ORM для меня единственный способ обновить таблицу базы данных, имея только значения идентификатора и описания, - это либо получить объект проекта из базы данных, установить описание, а затем отправить объект обратно в базу данных (что требует двух операций с базой данных). только для одного простого обновления) или для обновления с помощью хранимых процедур (это метод, который я сейчас использую).
Объекты и записи баз данных на самом деле не так уж и похожи. У них есть типизированные слоты, в которых можно хранить материал, но это все. Базы данных имеют совершенно иное понятие идентичности, чем языки программирования. Они не могут хорошо обрабатывать составные объекты, поэтому вместо них приходится использовать дополнительные таблицы и внешние ключи. В большинстве из них нет понятия наследования типов. А естественный способ навигации по сети объектов (следовать за некоторыми указателями в одном объекте, получить другой объект и снова разыменовать его) гораздо менее эффективен, если перенести его в мир баз данных, потому что вам придется совершать несколько обходов и извлекать множество данных, которые вас не интересуют.
Другими словами: абстракцию нельзя сделать очень хорошей в первую очередь; плохи не инструменты ORM, а метафора, которую они реализуют. Вместо совершенного изоморфизма получается лишь поверхностное сходство, поэтому сама задача не является очень хорошей абстракцией. (Тем не менее, это гораздо полезнее, чем необходимость досконально разбираться в базах данных. Презрение к инструментам ORM исходит в основном от DBA, которые смотрят свысока на простых программистов.)
.ORM пытаются решить очень сложную проблему. Существует огромное количество крайних случаев и основных компромиссов при проектировании, не имеющих четких или очевидных решений. Когда вы оптимизируете дизайн ORM для ситуации A, вы по своей природе делаете его неудобным для решения ситуации B.
Существуют ORM, которые "достаточно хорошо" обрабатывают ленивую загрузку и подзапросы, но почти невозможно перейти от "достаточно хорошо" к "отлично".
При разработке ORM вы должны хорошо представлять себе все возможные неудобные конструкции баз данных, которые ORM должен будет обрабатывать. Вы должны явно сделать компромиссные решения о том, какие ситуации вы готовы обрабатывать неловко.
Я не считаю ORM негибкими или более герметичными, чем ваша средняя сложная абстракция. Тем не менее, некоторые ORM лучше других в этом отношении.
Удачи в изобретении колеса.
ORM также могут писать неэффективный код. Поскольку производительность базы данных критически важна для большинства систем, они могут вызвать проблемы, которых можно было бы избежать, если бы код написал человек (но что могло бы быть не лучше, если бы этот человек не понимал настройку производительности базы данных). Это особенно верно, когда запросы становятся сложными.
Я думаю, что моя самая большая проблема с ними заключается в том, что, абстрагируясь от деталей, младшие программисты теряют понимание того, как писать запросы, которые им нужно иметь возможность обрабатывать крайние случаи и места, где ORM действительно пишет плохой код. Действительно сложно изучить сложные вещи, когда вам никогда не приходилось разбираться в основах. ORM в руках того, кто разбирается в объединениях, группировках и расширенных запросах, - это хорошо. В руках того, кто не понимает логическую алгебру, объединения и множество других базовых концепций SQL, это очень плохо, что приводит к очень плохому дизайну базы данных и запросов.
Реляционные базы данных не являются объектами и не должны рассматриваться как таковые. Попытки сделать из орла шелковый кошелек, как правило, не увенчаются успехом. Намного лучше узнать, в чем орел силен и почему, и позволить орлу летать, чем иметь плохой кошелек и мертвого орла.