Сравнение ORM-систем и ODANT

Сложить объекты в таблицы

Реляционные СУБД в свое время были очень хороши компактностью хранения и общей прямоугольной строгостью таблиц. Но загонять в эти рамки разнообразные данные стало непросто, тем более что в области бэкенда уже давно доминирует объектный подход. То есть, разбирая логику системы, мы видим: вот человек, его зовут Вася, он печет пончики, катается на велосипеде, женат на Маше, Маша работает в школе, где учатся их дети Петя и Коля. Каждая сущность в этой бытовой структуре — объект, будь то школа, велосипед или Коля, они обладают своими свойствами, связаны с другими объектами.

Я не хочу этим заниматься

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

Пусть работает компьютер

Чтобы решить кучу проблем с разработкой ИС, придумали ORM. Object-Relational Mapping, объектно-реляционное отображение или преобразование. Эта штука расположена между РСУБД и логикой бэкенда, теперь достаточно создать объект, и он будет автоматически разбросан по таблицам. Удобно, не нужно думать о том, как размещать пончики в БД. Чтобы писать поменьше кода вручную, добавим визуальные инструменты для создания классов и интерфейсов, и становится совсем красиво. Нужно создать справочник велосипедов — делаем несколько кликов мышкой.

Это же красиво и удобно:

  • разработка прикладного решения отделена от формирования запросов к БД, да и вообще от написания программного кода;
  • время на разработку сокращается — не надо каждый раз заниматься сравнительно низкоуровневыми задачами.

Если бы все было безоблачно…

  • ORM-системы характеризуются чрезвычайной прожорливостью, по некоторым оценкам до 95% машинного времени при работе систем уходит на объектно-реляционные преобразования. То есть, или дорого, или медленно, или дорого и медленно.
  • Сложно строить распределенные системы, поскольку РСУБД изначально разработаны для локальной централизованной работы.
  • Как сделать универсальную систему, чтобы автоматизировать вообще все и с любыми структурами данных — непонятно.

Храним объекты как объекты

Теперь, держа все эти плюсы и ужасы в голове, посмотрим на устройство ODANT. Она изначально объектная, нет таблиц, нет преобразований. Лихо экономим вычислительные ресурсы. Затем, архитектура ODANT распределенная, и никто не запрещает хранить информацию о Маше и школе на одном сервере, а велосипеды и Колю — на другом. Для этого есть уникальные глобальные идентификаторы, встроенный в ядро маршрутизатор и единая система безопасности. Наконец, можно реализовать любые нужные классы или пользовательские интерфейсы: все отдельными небольшими компонентами. Выберем нужные кубики, сложим их в систему для школы, не забыв про кафетерий с пончиками. А потом часть этих же кубиков, часть других, несколько придется разработать заново — и уже связаны в единую иерархическую сеть представительства транснациональной корпорации. Которая производит бульдозеры, карьерные экскаваторы и велосипеды.

Плюсы оставили, минусы убрали

А что с преимуществами хороших ORM-систем, такими как визуальное конструирование? Это в ODANT вообще часть идеологии. Из функционально законченных компонентов разработчик визуально собирает систему без единой строчки кода. Нет модуля, решающего требуемую задачу — тогда придется ставить задачу программистам. Зато новый компонент потом можно не только использовать в других решениях, но и продавать на торговой площадке.

Так что, если сравнивать ODANT с существующими ORM-системами, то сплошные плюсы: аппетиты к «железу» ниже, архитектура распределенная, область применения — любая. Ограничения, конечно, присутствуют. Нельзя взять и заменить РСУБД в имеющейся информационной системе на ODANT. И для эффективной разработки придется перестать «думать таблицами». Попытки имитировать привычное на новом фундаменте не работают.