Александр Свириденков

База данных обычно имеет не самостоятельную ценность, является частью информационной системы. Независимо от того, сколько звеньев имеет эта система, на противоположном от БД конце находится интерфейс взаимодействия с пользователем, и задача программиста предоставить простой и понятный способ работы с хранящимися в БД данными и объектами. При всей своей отлаженности и очевидности, классический способ хранения и представления объектов развитой структуры имеет и вполне определенные недостатки, с которыми сталкивался любой разработчик, пытавшийся реализовать таким способом достаточно сложную систему.

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

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

CUSTOMERS (

CUST_ID integer PK,

NAME varchar (200),

OKONH varchar(20),

OKPO varchar(20),

BIK varchar(20),

COUNTRY varchar(50),

CITY varchar(50),

...

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

Пока все, вроде бы, просто. За исключением того, что однотипные формы в программе плодятся как кролики, отчего многие не выдерживают, и создают свой язык описания подобных форм, для динамического их создания. Сложности возникают, если:

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

В некоторых ситуациях, решить эти проблемы позволяет хранение вариантной части объекта в виде XML c соответствующей XSD схемой. В этом случае мы:

1. Создаем табличку CUSTOMERS ( CUST_ID integer PK, NAME varchar (200), XML BLOB )
2. В XSD-редакторе определяем необходимые нам типы.

3. В приложении вызываем универсальную форму редактирования, которой передаем соответствующий тип XSD схемы, и XML карточку.

В примере, в качестве элемента редактирования используется адаптированный для работы с XML вариант Object Inspector.

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

Каковы преимущества данной схемы:

1. Даже на начальном этапе она менее трудоемка чем стандартная, и позволяет описывать объект в одном месте, причем как типы и размеры полей, так и их названия, заголовки и комментарии.
2. Описание структуры объектов полностью хранится в БД, приложение о ней может ничего не знать.
3. Средства описания форматов в XSD схемах заметно богаче набора типов данных сервера.

Source: www.ibase.ru

javakube описание атрибутов kubernetes deployment