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

В таблице приведены ряд критериев, по которым можно сравнить 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 ссылок

Еще одно понятие, которое присуще идеологии реляционных табличных БД. Рассмотрим простой пример.

[![](http://csc.odant.org/wp-content/uploads/2018/07/sch.jpg "")](http://csc.odant.org/wp-content/uploads/2018/07/sch.jpg "")

В таблице «Прайс-лист» информация о продавце товара дана только в виде кода продавца \(uid\). А все остальное — в таблице «Продавцы». Если нужно получить прайс-лист, в который будет вставлена информация о продавце, выполняется SQL запрос, которые объединит данные таблиц «Прайс-лист» и «Продавцы».

Подобная реализация в ODANT возможна, но обычно не применяется. В ODANT в прайс-листе атрибут, связанный с продавцом, будет включать в себя необходимое описание этого продавца \(как минимум — название, может быть адрес, телефон, а может — полные реквизиты\). При этом можно установить связь этого атрибута с классом «Продавцы», и в этой связи будет информация по uid продавца. Но поведение этой связи сложное и настраивается в зависимости от прикладной задачи. Связь бывает статической или динамической, можно настроить, какая часть информации из объекта «Продавец» будет импортироваться.

Контроль ссылочной целостности в реляционных БД подразумевает следующее. Если мы попытаемся удалить запись в таблице «Продавцы», на которую ссылается запись в таблице «Прайс-лист», то SQL эту операцию заблокирует. Этот контроль нам необходим, так как данные о продавце есть только в записи таблицы «Продавцы». Но в ODANT все не так. Данные о продавце есть в объекте «Прайс-лист». И в случае удаления объекта из класса «Продавцы» данные этого продавца останутся. Поэтому контроля ссылочной целостности в том виде, как это реализовано в табличных БД, в ODANT нет.

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