Возможности и перспективы XML-документов
В прошлый раз я намекнул, что XML-документы могут достаточно продуктивно использоваться в системах документооборота. Как именно – попробуем разобрать на примерах.
В прошлый раз я намекнул, что XML-документы могут достаточно продуктивно использоваться в системах документооборота. Как именно – попробуем разобрать на примерах.
XML-документ – прекрасный способ хранить информацию, которая используется многократно в разных вариантах. Например, информацию о телефонах отделов компании, которые публикуются на веб-сайт или в рекламный буклет. XML-документ обрабатывает подсистема публикации СЭД. Применение схемы преобразований на основе XSLT позволит придать нужный внешний вид документу.
XML-документ удобен для хранения слабо структурированных данных, для которых нет смысла создавать отдельную «навороченную» карточку или справочники. Например, данные о сроках курсов обучения или о скидках поставщиков: их не только нужно публиковать, но и искать информацию в них.
Для того, чтобы искать данные в XML, можно применять либо отдельные приложения, либо (для хранилищ документов на базе Microsoft SQL Server 2005) можно пользоваться обычным полнотекстовым поиском. При этом не только идет разделение слов по тегам, но и появляются дополнительные возможности поиска с учетом структуры XML-документа (применяется довольно несложный язык запросов XQuery):
|
Конечно, это условный пример, и не все СЭД сейчас готовы предоставить функции поиска по XML-документам. Однако очевидные преимущества XML - способность чтения человеком и машиной, структуризация данных, удобный поиск – способны в значительной степени повлиять на его применение в системах документооборота.
Комментарии 2
Сама мысль, что за счет своей гибкости XML позволяет хранить слабоструктурированные данные (то есть данные, структура которых может довольно легко меняться, например, от экземпляра к экземпляру) представляется вполне здравой! Действительно, если разработчик, например, при проектировании модели данных не внес какое-нибудь поле (например, в карточке договора не предусмотрел возможность указания нескольких банковских реквизитов), то у заносящего документ не будет с этим больших проблем - добавил новый тег и порядок!
НО система, то о том, что на самом деле модель данных изменилась не знает ровным счетом ничего! Никто не проектировал логику на то, что банковских реквизитов будет не один, а несколько!
А дальше уже вообще-то может случиться одна из 3-х вещей:
Если честно, 2 и 3 случай - явные ошибки, а 1... тут возникает резонный вопрос - надо ли было вообще что-то структурировать?
Идея действительно интересная. Возможность динамически изменить структуру карточки, и что главное, для отдельных записей, а не всей таблицы, позволит хранить в одном списке (его уже трудно будет назвать таблицей) разную информацию. С другой стороны, при переменной длине записи, добавление нового поля к существующей записи ведет к появлению фрагментации базы данных.
Интересно будет выглядеть поиск и фильтрация данных. Например, если требуется найти всех клиентов, адрес головного офиса у которых Москва, то надо сначала будет найти те записи, которые содержат тег "Адрес головного офиса", а потом уже среди них искать те, что содержат в значении этого поля текст "Москва".
Для того, чтобы информация в такой таблице была более или менее структурирована, придется вводить постоянную и переменную часть записи: постоянная часть содержит обязательные для присутсвия (не путать с обязательными для заполнения) теги, а переменная - перечень тегов, которые встречаются не во всех записях.