int(1)

Что такое Объектно-реляционные преобразователи (ORM)?

Turing Bootcamp 10.09.2021 0

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

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

Например, без ORM разработчик написал бы следующий оператор SQL для извлечения каждой строки в таблице USERS, где zip_codeстолбец — 94107:

Вместо этого эквивалентный запрос ORM Django будет выглядеть как следующий код Python:

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

ORM также теоретически позволяют переключать приложение между различными реляционными базами данных. Например, разработчик может использовать SQLite для локальной разработки и MySQL в производственной среде . Производственное приложение можно было переключить с MySQL на PostgreSQL с минимальными изменениями кода.

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

Должен ли я использовать ORM для моего веб-приложения?
Библиотеки Python ORM не требуются для доступа к реляционным базам данных. Фактически, низкоуровневый доступ обычно предоставляется другой библиотекой, называемой коннектором базы данных , такой как psycopg (для PostgreSQL) или MySQL-python (для MySQL). Взгляните на таблицу ниже, в которой показано, как ORM могут работать с различными веб-фреймворками, коннекторами и реляционными базами данных.

Примеры того, как разные ORM Python могут работать с разными коннекторами и бэкэндами.

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

Каковы недостатки использования ORM?
У ORM есть множество недостатков, в том числе:

— Несоответствие импеданса
— Возможность снижения производительности
— Перенос сложности из базы данных в код приложения
— Несоответствие импеданса

Фраза «несоответствие импеданса» обычно используется в связи с ORM. Несоответствие импеданса — это общий термин для обозначения трудностей, возникающих при перемещении данных между реляционными таблицами и объектами приложения. Суть в том, что то, как разработчик использует объекты, отличается от того, как данные хранятся и объединяются в реляционных таблицах.

Эта статья о несоответствии импеданса ORM представляет собой серьезную работу по объяснению концепции на высоком уровне и предоставляет диаграммы для визуализации причин возникновения проблемы.

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

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

В этом разделе много размахиваний руками «может или не может» и «потенциал для». В крупных проектах ORM достаточно хороши примерно для 80-90% случаев использования, но в 10-20% взаимодействий с базой данных проекта могут быть значительные улучшения производительности, если опытный администратор базы данных напишет настроенные операторы SQL для замены сгенерированного ORM кода SQL. .

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

— Реализации Python ORM
Существует множество реализаций ORM, написанных на Python, в том числе:

— SQLAlchemy
— Peewee
— Django ORM
— PonyORM
— SQLObject
— ORM ( исходный код )
Существуют и другие ORM, такие как Canonical’s Storm , но большинство из них, похоже, в настоящее время не находится в активной разработке. Узнайте больше об основных активных ORM ниже.

— ORM Джанго
Django фреймворк поставляется с собственным встроенным в объектно-реляционного отображения модуля , как правило , называют как «Джанго ОРМ» или «ОРМ Джанго».

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

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

Поскольку большинство проектов Django привязано к ORM по умолчанию, лучше всего ознакомиться с расширенными вариантами использования и инструментами, чтобы лучше всего работать в существующей структуре.

SQLAlchemy ORM
SQLAlchemy — это хорошо зарекомендовавшая себя ORM Python, потому что она получает уровень абстракции «в самый раз» и, кажется, в большинстве случаев упрощает написание сложных запросов к базе данных, чем Django ORM. На SQLAlchemy есть целая страница, которую вы должны прочитать, если хотите узнать больше об использовании библиотеки.

Peewee ORM
Peewee — это реализация ORM Python, которая написана так, чтобы быть « проще, меньше и легче взламывать », чем SQLAlchemy. Прочтите полную страницу Peewee для получения дополнительной информации о реализации Python ORM.

Pony ORM
Pony ORM — это еще одна ORM для Python, доступная в виде открытого исходного кода под лицензией Apache 2.0.

SQLObject ORM
SQLObject — это ORM, который активно разрабатывался с открытым исходным кодом более 14 лет, начиная с 2003 года .

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

Миграция схемы базы данных — сложная тема и заслуживает отдельной страницы. На данный момент мы объединим ресурсы миграции схемы по ссылкам ORM ниже.

Общие ресурсы ORM
Этот подробный обзор ORM является общим описанием того, как работают ORM и как их использовать.

Этот пример проекта GitHub реализует одно и то же приложение Flask с несколькими разными ORM: SQLAlchemy, Peewee, MongoEngine, stdnet и PonyORM.

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

Если вас смущает разница между соединителем, таким как MySQL-python, и ORM, например SQLAlchemy, прочтите этот ответ StackOverflow по этой теме.

Чему меня научили ORM: просто изучите SQL — это еще один аспект дискуссии ORM по сравнению со встроенным SQL / хранимыми процедурами. Автор приходит к выводу, что при работе с ORM, такими как SQLAlchemy и Hibernate (ORM на основе Java), можно заранее сэкономить время, по мере развития проекта возникают проблемы, такие как частичные объекты и избыточность схемы. Я думаю, что автор делает некоторые веские аргументы в пользу того, что некоторые ORM могут быть шаткой основой для чрезвычайно сложных приложений с поддержкой баз данных. Однако я не согласен с главным выводом о том, чтобы отказаться от ORM в пользу хранимых процедур. У хранимых процедур есть свои проблемы, и нет идеальных решений, но я лично предпочитаю использовать ORM в начале почти каждого проекта, даже если позже его нужно будет заменить прямыми SQL-запросами.

Вьетнам компьютерных наук представляет точку зрения Теда Ньюарда, создателя фразы «Объектное / реляционное отображение — это Вьетнам компьютерных наук», о которой он впервые заговорил в 2004 году. Суть аргумента против ORM отражена в цитате Теда, что ORM «представляет собой болото, которое начинается хорошо, со временем усложняется и вскоре вовлекает пользователей в обязательства, не имеющие четкой точки разграничения, четких условий выигрыша и четкой стратегии выхода». Есть последующие посты о Coding Horror и еще одно от Теда, озаглавленное « Мысли о комментарии о Вьетнаме» .

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

Стань программистом за 3 месяца с нами! Подробности по ссылке.

Поделиться
Интересные статьи:
Turing Bootcamp 02.08.2021 Что такое Full Stack Developer? Необходимые ключевые навыки - Разработчик полного стека помогает поддерживать бесперебойную работу каждой части системы - Разработчик полного цикла может помочь каждому в команде...
Turing Bootcamp 30.08.2021 Шпаргалка по JavaScript Если вы хотите создавать динамические веб-страницы, вам придется дополнить свои знания HTML и CSS пониманием JS . Этот язык...
Turing Bootcamp 06.09.2021 В чем разница между REACT.JS И REACT NATIVE? React Native React Native - это фреймворк для создания собственных приложений с использованием JavaScript. React Native компилируется в собственные компоненты...