Журнал о системах электронного документооборота (СЭД)
Управление контентом

Возможности и перспективы XML-документов

  2 комментариев Добавить в закладки

В прошлый раз я намекнул, что XML-документы могут достаточно продуктивно использоваться в системах документооборота. Как именно – попробуем разобрать на примерах.

XML-документ – прекрасный способ хранить информацию, которая используется многократно в разных вариантах. Например, информацию о телефонах отделов компании, которые публикуются на веб-сайт или в рекламный буклет. XML-документ обрабатывает подсистема публикации СЭД. Применение схемы преобразований на основе XSLT позволит придать нужный внешний вид документу.

XML-документ удобен для хранения слабо структурированных данных, для которых нет смысла создавать отдельную «навороченную» карточку или справочники. Например, данные о сроках курсов обучения или о скидках поставщиков: их не только нужно публиковать, но и искать информацию в них.

Для того, чтобы искать данные в XML, можно применять либо отдельные приложения, либо (для хранилищ документов на базе Microsoft SQL Server 2005) можно пользоваться обычным полнотекстовым поиском. При этом не только идет разделение слов по тегам, но и появляются дополнительные возможности поиска с учетом структуры XML-документа (применяется довольно несложный язык запросов XQuery):


  SELECT *
  FROM   DocumentStorage
  WHERE  Document.exist('/company/discount/text()[contains(.,"10")]')=1

Конечно, это условный пример, и не все СЭД сейчас готовы предоставить функции поиска по XML-документам. Однако очевидные преимущества XML - способность чтения человеком и машиной, структуризация данных, удобный поиск – способны в значительной степени повлиять на его применение в системах документооборота.

Ещё материалы автора
Похожие записи
Комментарии (2)
Михаил Романов 20 апреля 2007 г. 09:02  
Все-таки, так и не увидел до конца преимущества использования именно XML-структур в документообороте...
Сама мысль, что за счет своей гибкости XML позволяет хранить слабоструктурированные данные (то есть данные, структура которых может довольно легко меняться, например, от экземпляра к экземпляру) представляется вполне здравой! Действительно, если разработчик, например, при проектировании модели данных не внес какое-нибудь поле (например, в карточке договора не предусмотрел возможность указания нескольких банковских реквизитов), то у заносящего документ не будет с этим больших проблем - добавил новый тег и порядок!
НО система, то о том, что на самом деле модель данных изменилась не знает ровным счетом ничего! Никто не проектировал логику на то, что банковских реквизитов будет не один, а несколько!
А дальше уже вообще-то может случиться одна из 3-х вещей:
1. Система просто "не заметит" новый тег.
2. Произойдет сбой (какой из двух реквизитов использовать?).
3. В обработку попадут не те данные - выбирется дополнительный тег (если структура его известна системе).
Если честно, 2 и 3 случай - явные ошибки, а 1... тут возникает резонный вопрос - надо ли было вообще что-то структурировать?
Сергей Бушмелев 27 апреля 2007 г. 15:39  
 

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

Интересно будет выглядеть поиск и фильтрация данных. Например, если требуется найти всех клиентов, адрес головного офиса у которых Москва, то надо сначала будет найти те записи, которые содержат тег "Адрес головного офиса", а потом уже среди них искать те, что содержат в значении этого поля текст "Москва".

Для того, чтобы информация в такой таблице была более или менее структурирована, придется вводить постоянную и переменную часть записи: постоянная часть содержит обязательные для присутсвия (не путать с обязательными для заполнения) теги, а переменная - перечень тегов, которые встречаются не во всех записях.

Сейчас обсуждают
Больше комментариев