В таблице приведены ряд критериев, по которым можно сравнить ODANT с реляционной СУБД MS SQL. Ниже — комментарии по некоторым вопросам.
| № | Характеристика | Реализация в ODANT | Реализация в MS SQL |
| 1 | Универсальные свойства СУБД | ||
| 1.1 | Транзакционность | В терминах реляционной базы данных нет. Развернутый комментарий ниже. | Есть |
| 1.2 | Целостность | Есть. Развернутый комментарий ниже. | Есть |
| 1.3 | Ключи | Есть | Есть |
| 1.4 | Индексы | Есть | Есть |
| 1.5 | Язык запросов | XQuery | T-SQL |
| 1.6 | Процедуры | Есть. Реализуются в виде классов, которые предоставляют свои методы другим классам. | Есть |
| 1.7 | Функции | Есть. Реализуются в виде классов, которые предоставляют свои методы другим классам. | Есть |
| 1.8 | Job | Есть. Реализуется в виде классов, код методов которых выполняется на сервере. Запуск выполнения по событиям возможен. | Есть |
| 1.9 | Контроль uid ссылок. (при изменении источника кеш не обновляется в зависимых объектах) | Ссылка, аналогичная uid ссылке в реляционной базе данных, не используется в ODANT по идеологическим причинам, хотя технически она реализуема. В ODANT используется понятие связи, у которой другое поведение. | Есть |
| 2 | Администрирование, инструменты разработки | ||
| 2.1 | Трекинг запросов | Есть. Изменение базы данных происходит ВСЕГДА через изменение объектов. Отслеживание изменений объектов реализовано. | Есть |
| 2.2 | План запроса | Нет | Есть |
| 2.3 | Управление доступом к таблицам/классам | Есть | Есть |
| 2.4 | Шифрование, анонимизация данных в БД | Техническая возможность есть, необходимо получение лицензии | Есть |
| 2.5 | Редактор запросов | Есть | Есть |
| 2.6 | Автоматическое резервное копирование | Есть | Есть |
| 2.7 | Автоматический Shrink | Нет. Не требуется, связано с архитектурой базы данных. База всегда оптимизирована по размеру. | Есть |
| 3 | Интеграция с другими СУБД | ||
| 3.1 | Подключение к другим СУБД | Реализуется на прикладном уровне. Сейчас есть сервисный класс для подключения к другим базам данных через ODBC, с возможностью импорта. Также возможен импорт из других источников: Excel, csv файлы и др. | Есть |
| 3.2 | Выполнение выборки данных из другой СУБД | При выполнении импорта с использованием ODBC драйвера возможно выполнение выборки с помощью SQL запросов. | T-SQL |
| 4 | Использование различных приложений | ||
| 4.1 | Доступ к данным из приложений | Через коннектор, разработанный для данного приложения. Можно использовать уже существующие коннекторы (например, для 1С). | Через стандартные драйвера |
| 5 | Объектная модель работы с данными | ||
| 5.1 | Наследование | Есть | Нет |
| 5.2 | Иерархическая БД | Есть | Нет |
| 5.3 | Простое построение и работа со сложными структурами данных. Возможность отображать сложные сущности внешнего мира в одном классе. | Есть | Нет |
| 5.4 | Общий репозиторий методов | Есть | Нет |
| 5.5 | Распределенные хранение и обработка данных | Есть | Нет |
| 5.6 | Глобальная идентификация сущностей | Есть | Нет |
| 5.7 | Создание модели данных, которая включает в себя зависимости между данными | Есть | Нет |
| 5.8 | Возможность обмена (продажи) между разработчиками частями базы данных (классов). Возможность построение базы данных из частей базы данных (классов), созданных другими разработчиками. | Есть | Нет |
| 5.9 | Возможность использовать при построении базы данных сервисы с данными (например, поле адреса), которые поставляются другими разработчиками. | Есть | Нет |
| 5.10 | Возможность синхронизации моделей данных через общие репозитарии моделей данных между различными разработчиками | Есть | Нет |
Транзакционность
При изменении данных БД должна переходить от одного целостного состояния к другому. Однако, в процессе обновления данных возможны ситуации, когда состояние целостности нарушается. Во избежание таких ситуаций в СУБД вводится понятие транзакции — атомарного действия над БД, переводящего ее из одного целостного состояния в другое целостное состояние. Другими словами, транзакция — это последовательность операций, которые должны быть или все выполнены или все не выполнены (все или ничего).
Понятие транзакции было разработано и реализовано в эпоху табличных реляционных баз данных. В таких БД прикладные сущности, как правило, не могут быть реализованы в одной таблице, а располагаются сразу в нескольких связанных таблицах. В этом случае операция в БД с одной прикладной сущностью требует обращения сразу к нескольким таблицам. При этом могут возникать различные проблемы, связанные как с прерыванием операций, так и со случаями параллельной работы нескольких пользователей с одними и теми же сущностями.
В объектной базе данных ODANT прикладная сущность описывается одним классом, а действие производится над объектом класса. В ODANT сервер контролирует целостность сущности — объекта — при операциях с ним. Можно говорить о том, что механизм транзакций, который обеспечивает целостность БД, реализован на уровне сервера, не требуя дополнительного управления на уровне программиста. При этом механизма транзакций, привычного специалистам по работе с SQL СУБД — нет.
Целостность объектной БД — это целостность объектов, которая контролируются сервером. Для полноценной работы этого механизма необходимо построение правильной структуры данных.
У программистов, которые ранее работали только с табличными реляционными БД, возникает проблема при переходе на объектную СУБД ODANT. Они в процессе разработки пытаются реализовать структуру данных аналогичную той, которую они применяют в РСУБД. И при работе с этой структурой у них возникает потребность в транзакционности. Данная проблема решается формированием правильной структуры данных и идеологией построения приложений.
Контроль uid ссылок
Еще одно понятие, которое присуще идеологии реляционных табличных БД. Рассмотрим простой пример.
В таблице «Прайс-лист» информация о продавце товара дана только в виде кода продавца (uid). А все остальное — в таблице «Продавцы». Если нужно получить прайс-лист, в который будет вставлена информация о продавце, выполняется SQL запрос, которые объединит данные таблиц «Прайс-лист» и «Продавцы».
Подобная реализация в ODANT возможна, но обычно не применяется. В ODANT в прайс-листе атрибут, связанный с продавцом, будет включать в себя необходимое описание этого продавца (как минимум — название, может быть адрес, телефон, а может — полные реквизиты). При этом можно установить связь этого атрибута с классом «Продавцы», и в этой связи будет информация по uid продавца. Но поведение этой связи сложное и настраивается в зависимости от прикладной задачи. Связь бывает статической или динамической, можно настроить, какая часть информации из объекта «Продавец» будет импортироваться.
Контроль ссылочной целостности в реляционных БД подразумевает следующее. Если мы попытаемся удалить запись в таблице «Продавцы», на которую ссылается запись в таблице «Прайс-лист», то SQL эту операцию заблокирует. Этот контроль нам необходим, так как данные о продавце есть только в записи таблицы «Продавцы». Но в ODANT все не так. Данные о продавце есть в объекте «Прайс-лист». И в случае удаления объекта из класса «Продавцы» данные этого продавца останутся. Поэтому контроля ссылочной целостности в том виде, как это реализовано в табличных БД, в ODANT нет.
