Сравнение СУБД: MS SQL и ODANT

В таблице приведены ряд критериев, по которым можно сравнить ODANT с реляционной СУБД MS SQL. Ниже — комментарии по некоторым вопросам.

ХарактеристикаРеализация в ODANTРеализация
в MS SQL
1Универсальные свойства СУБД
1.1ТранзакционностьВ терминах реляционной базы данных нет. Развернутый комментарий ниже.Есть
1.2ЦелостностьЕсть. Развернутый комментарий ниже.Есть
1.3КлючиЕстьЕсть
1.4ИндексыЕстьЕсть
1.5Язык запросовXQueryT-SQL
1.6ПроцедурыЕсть. Реализуются в виде классов, которые предоставляют свои методы другим классам.Есть
1.7ФункцииЕсть. Реализуются в виде классов, которые предоставляют свои методы другим классам.Есть
1.8JobЕсть. Реализуется в виде классов, код методов которых выполняется на сервере. Запуск выполнения по событиям возможен.Есть
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 нет.

Еще раз отметим, если мы захотим, то сможем с помощью XQuery получить результат как при выполнении SQL запроса.