Хранение данных в объектах ODANT
СУБД ODANT не является реляционной, и подход к хранению данных в ней отличается от привычного для разработчиков систем на РСУБД. Как все это работает, будем пояснять на простых примерах.
Полезная избыточность
На концепцию РСУБД сильно повлияло то, что «тогда» объемы накопителей были малы, стоили они очень дорого, а общий подход к рабочему процессу выглядел как «система — это мейнфрейм и клиенты». С точки зрения компактности хранения идея хорошая, когда данные хранятся в одной таблице, а в остальных — только ссылки на нее. Но с позиций производительности, надежности, гибкости, возможностей распределения — не очень.
Собственно, пример. Есть справочник товаров, есть договоры поставки. В случае с таблицами структура проиллюстрирована выше. Создадим такую конструкцию в ODANT. Начнем с класса «Товары» с полями «Артикул», «Наименование» и «Цена». В этом классе создан объект, соответствующий товару — десятилитровой оцинкованной лейке.
Теперь — к договорам. Класс «Договоры» содержит поле «Контрагент» и табличное поле с парами элементов «Товар» и «Количество». Тип первого элемента — класс «Товар». Конечно, контрагента тоже нужно брать из справочника, но не будем усложнять пример.
В классе «Договоры» создаем объект и смотрим, как он выглядит в XML-представлении.
То есть, в объекте договора упомянута связь с другим объектом, но данные продублированы. Теперь для работы с этим договором нам уже не нужен справочник товаров, все необходимое сосредоточено в одном объекте. А это значит, например, что…
- Можно изменить цену в справочнике. В договоре она останется прежней без дополнительных ухищрений. Впрочем, тут как настроить — можно сделать и автоматическое обновление поля.
- С договором можно работать автономно. Неважно, где находится сервер со справочником, он нам понадобится только при добавлении новой позиции или создания нового договора.
