В прошлой статье я набросал список задач (далеко не полный), какие решает программист уровня Middle в компании, являющейся крупным оператором грузовых вагонов. А сегодня хочу рассказать об одной из них, а именно — получение и сохранение перевозочных документов­.

Предположим, крупный импортер фруктов «Василёк» договорился с ритейлером «Ромашка» о поставке на их склад пятидесяти тонн апельсинов — этих сочных и ярких даров южного солнца. Как это зафиксировать в документообороте? На помощь приходит XML (eXtensible Markup Language — расширяемый язык разметки). Это текстовый формат, в котором передаются структурированные данные между разными системами. Например, между корпоративной ИС оператора вагонов и автоматизированной системой ЭТРАН (Электронная Транспортная Накладная). В этом формате передаются «Счёт-фактура», «Заявка на перевозку» и многие другие виды перевозочных документов.

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

В одной накладной можно указать несколько грузов. Это просто замечательно — вдруг «Ромашка» закажет у «Василька» еще тонн тридцать лимонов к чаю. XML хранит данные в виде дерева (иерархическом), что позволяет передать всю структуру вложенности элементов. Поэтому на каждый груз, например, можно проставить несколько отметок с дополнительной информацией. Или на каждом из вагонов указать проводников, сопровождающих груз.

Всё прекрасно, но информация в базе данных хранится в реляционном виде! Проще говоря, в виде таблиц. Пользователям нужно запрашивать какие-то сведения или агрегаты. Например, менеджеру по закупкам «Ромашки» понадобится узнать суммарную массу апельсинов, закупленных в каждом месяце прошлого года и сравнить её с аналогичными показателями года текущего. Обращаться напрямую к элементам XML хотя и можно, но долго и затратно, недаром же в 70-х годах прошлого века были придуманы таблицы!

Как же превратить данные из древовидного вида в табличный? На помощь приходят встроенные средства. Функция XMLTABLE, существующая в коммерческих и бесплатных СУБД, формирует таблицу из XML-значения, обращаясь напрямую к элементам и позволяя назначить для них имена и типы данных. Этот процесс называется «разбор», или «парсинг», и позволяет легко и просто записать результаты напрямую в целевую таблицу. При этом дочерние и внучатые элементы (всё те же грузы и отметки на груз) тоже имеют все шансы быть записанными в соответствующие им таблицы. Достаточно, чтобы в каждой из них присутствовал составной первичный ключ, состоящий из идентификатора накладной и номера (номеров) дочернего элемента.

При таком подходе превосходно сохраняется вся взаимосвязь сущностей, и можно сохранить потомков хоть до седьмого колена, если такая необходимость возникнет.

А если потребуется переслать какую-то информацию партнёрам? Тогда снова выручает XML. В этом случае выполняется обратная операция: извлекаются данные из самых-самых «внучатых» таблиц, оформляются в теги функцией XMLELEMENT и оборачиваются снаружи корневым элементом. Затем этот процесс повторяется уровнем выше и так далее вплоть до головной таблицы.

— А как же JSON, ведь он значительно компактнее? — спросит продвинутый читатель? Верно, вот только за счёт мощных средств для описания сложных структур и возможности строгой проверки данных XML намного лучше подходит для использования в корпоративных системах. Этому также способствуют поддержка пространств имён, цифровые подписи и другие возможности стандарта. Вдобавок, субъективно, документ, оформленный в этом стиле, приятно читать, открыв его в текстовом редакторе с подсветкой синтаксиса.

Бизнес не должен находиться перед выбором между скоростью передачи данных и удобством их обработки. Ему важно использовать оба этих преимущества, и существующие технологии дают для этого прекрасную возможность.

#xml #этран