ORM — палка о двух концах в управлении реляционными базами данных

Что такое ОРМ?

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

Введите объектно-реляционное сопоставление.

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

Звучит здорово! Всем должно понравиться это!

Ну... некоторые, конечно, делают.

ORM — палка о двух концах

Тема ORM может вызывать разногласия, и вы, вероятно, получите разные мнения по этому поводу в зависимости от того, с кем вы разговариваете. Возможно, вы слышали фразу Object-Relational Mapping — это Вьетнам нашей отрасли?. Эту аналогию провел в 2004 году Тед Ньюард, ныне директор по технологической культуре в Quicken Loans. 16 лет спустя это мнение все еще разделяют многие разработчики.

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

Существует множество популярных ORM, наиболее широко используемыми из которых являются Django и SQLAlchemy для Python, Active Record для Ruby on Rails и Hibernate для Java. Даже Javascript, который является объектно-ориентированным, но не основанным на классах, содержит популярные библиотеки ORM, такие как Sequelize, TypeORM и Knex с Bookshelf.

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

Давайте углубимся в это.

Преимущества объектно-реляционного отображения

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

Нужен небольшой учебник по абстракции?

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

Эта абстракция является источником всех преимуществ использования ORM.

Написание запросов на таких языках, как Python или Ruby, вместо SQL обеспечивает согласованность кода. Хотя некоторые разработчики могут не возражать против переключения между операторами SQL и другим языком, написание программы на одном удобном для вас языке может увеличить скорость разработки, особенно на начальных этапах. SQL-запросы также могут стать трудными для понимания по мере роста их размера и сложности, поэтому возможность использовать объекты для управления своими данными может упростить обновление и обслуживание.

ORM также могут сделать ваш код более СУХИМ. SQL-запросы имеют много специфического «шаблонного» синтаксиса, который часто повторяется в приложении. Избегая этого синтаксиса, вы можете писать меньше этого повторяющегося ненужного кода.

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

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

Недостатки объектно-реляционного отображения

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

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

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

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

Итак, стоит ли вам использовать ORM?

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

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

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

Каким бы ни было ваше собственное мнение, вы хотите управлять своей базой данных максимально эффективно.