Хранение информации



Структуры Хранения Баз Данных

Применение XML в реляционных БД для хранения объектов сложной структуры  Октябрь 12, 2016 – 06:18
Александр Свириденков
База данных обычно имеет не самостоятельную ценность, является частью информационной системы. Независимо от того, сколько звеньев имеет эта система, на противоположном от БД конце находится интерфейс взаимодействия с пользователем, и задача программиста предоставить простой и понятный способ работы с хранящимися в БД данными и объектами. При всей своей отлаженности и очевидности, классический способ хранения и представления объектов развитой структуры имеет и вполне определенные недостатки, с которыми сталкивался любой разработчик, пытавшийся реализовать таким способом достаточно сложную систему.

Рассмотрим довольно стандартную ситуацию. В системе необходимо реализовать учет покупателей, со всеми их реквизитами, а таже, естественно, предоставить возможность их просмотра и редактирования. В классическом варианте нам необходимо:

  1. Создать табличку

CUSTOMERS (

CUST_ID integer PK,

NAME varchar (200),

OKONH varchar(20),

OKPO varchar(20),

BIK varchar(20),

COUNTRY varchar(50),

CITY varchar(50),

...

  1. Создать форму редактирования с Label и DBEdit элементами, привязать их к соответствующим полям DataSet-а, и реализовать обычные обработчики кнопок "Добавить", "Удалить", "Изменить".

Пока все, вроде бы, просто. За исключением того, что однотипные формы в программе плодятся как кролики, отчего многие не выдерживают, и создают свой язык описания подобных форм, для динамического их создания. Сложности возникают, если:
  • мы хотим вести учет не только юридических, а еще и физических лиц, для которых нужны дополнительные атрибуты, которые становятся бессмысленными для юрлиц (и наоборот).
  • в процессе работы системы возникла необходимость добавить новый атрибут. Та же цепочка – поле в таблицу, изменения на форме, новая структура метаданных БД, новая программа.
  • число некоторых атрибутов заранее неивестно. Например, у организации может быть один телефон, 2, 3..10.
  • система тиражируема, и в различных инсталляциях наборы атрибутов различаются кардинально.

В некоторых ситуациях, решить эти проблемы позволяет хранение вариантной части объекта в виде XML c соответствующей XSD схемой. В этом случае мы:
  1. Создаем табличку CUSTOMERS ( CUST_ID integer PK, NAME varchar (200), XML BLOB )
  2. В XSD-редакторе определяем необходимые нам типы.
  1. В приложении вызываем универсальную форму редактирования, которой передаем соответствующий тип XSD схемы, и XML карточку.

В примере, в качестве элемента редактирования используется адаптированный для работы с XML вариант Object Inspector.
За основу был взял TZPropList от Genadie Zuev, благо он бесплатный и с исходниками. Таким же образом можно доработать любой Object Inpector – На входе он получает ссылку на два XML узла – XSD схема и собственно редактируемый объект. Если объект пустой, он создается на основе XSD схемы. Результат виден на картинках. Дополнительные бонусы – автозавершение и выпадающие списки для перечислимых типов, учет форматов и масок для прочих типов.
Каковы преимущества данной схемы:
  1. Даже на начальном этапе она менее трудоемка чем стандартная, и позволяет описывать объект в одном месте, причем как типы и размеры полей, так и их названия, заголовки и комментарии.
  2. Описание структуры объектов полностью хранится в БД, приложение о ней может ничего не знать.
  3. Средства описания форматов в XSD схемах заметно богаче набора типов данных сервера.

Source: www.ibase.ru

Похожие публикации:

  1. Структура Хранения Данных 1С 8.3
  2. Структура Хранения Данных 1С
  3. Структура Хранения Базы Данных 1С
  4. Структуры Хранения Данных
  5. Архитектура Хранения Данных