Перейти к содержанию

Об обработке данных с использованием Xml


Рекомендуемые сообщения

Является ли XML панацеей?

 

 

Дон Петерсон (Don Peterson)

 

 

В этой статье Дон Петерсон анализирует, почему ему? не нравится XML! Здесь

есть несколько интересных утверждений, и, если вы раньше не задумывались,

что XML значит для вас как для администратора баз данных, то эта статья

заслуживает внимания.

 

 

Когда у меня появились первые наброски этой статьи, XML был одним из самых

модных терминов. Он вел всех нас в абсолютно новый мир, где системы будут

легко интегрироваться силами этих маленьких магических тэгов? Только

представьте, как было бы замечательно хранить все данные в формате XML!

Системы управления базами данных на основе XML, несомненно, станут

следующим эволюционным шагом, который наконец уничтожит impedance mismatch

(несоответствие объектной и реляционной моделей). Каждый уважающий себя

поставщик программного обеспечения просто должен будет использовать XML

везде! Все, что преподносилось как неоспоримые преимущества этого решения,

вызвало у меня подозрения. Я решил разобраться в причинах такого ажиотажа.

После многих месяцев исследований и тестирования я пришел к выводу, что XML

не только не является решением любой глобальной проблемы управления или

обмена данными, но что это достаточно глупый ответ на все неправильные

вопросы! Более того, стало ясно, что XML фактически является гигантским

прыжком в неверном направлении, увековеченным теми, кто не знает или не

понимает основ управления данными.

 

 

Изначально статья была внутренним документом, который я отправил менеджерам

в попытке урезонить программистов, которые вставляли XML в большие поля

varchar в базе данных. Мои усилия были в основном успешными. Политика

компании изменилась, позволяя теперь программистам использовать XML только

для коммуникации, но не для хранения в базе данных. К сожалению, многие из

наших по?ставщиков изменили свои продукты для использования XML, и во всех

без исключения случаях мы столкнулись с проб?лемами ? от увеличившегося

объема для хранения данных до сильно раздувшихся файлов журнала и абсолютно

неэффективных запросов. По предложению моего менеджера я отредактировал

документ и отослал его в SQL Server Central. Я никогда не думал, что он

будет опубликован, поскольку он противоречил мнению большинства и был, как

сказали бы некоторые, подстрекательским. К моему удивлению, я получил много

содержательных и поддерживающих мое мнение комментариев.

 

 

Сейчас XML уже не является модным термином, но, к сожалению, он крепко

укоренился почти в каждом подходе к управлению данными. Я, как и многие

другие, все еще придерживаюсь глубокого убеждения, что XML не решает

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

в действительности вызывает даже больше проблем, чем может потенциально

решить.

 

 

Несмотря на маркетинговые требования главных поставщиков и желание шагать в

ногу со временем, было бы разумным точно проверить, какие преимущества

предлагает XML, и сравнить их с затратами, прежде чем необдуманно

погружаться в XML с головой.

 

 

Идея XML довольно проста: вы просто добавляете тэги в файл данных. Эти тэги

иногда интерпретируются как метаданные. XML по своей сути строго

иерархичен. Ниже представлены основные преимущества, которые усиленно

расхваливаются:

самоописание данных;

облегчение межплатформенного совместного использования данных или

?свободное соединение? приложений;

простота моделирования ?неструктурированных? данных.

 

 

Самоописание данных

 

 

Идея самоописываемых данных звучит великолепно, но давайте разберемся в

подробностях. Ниже представлен классический пример самоописания данных в

XML:

 

 

<Product>Shirt

<Color>Red</Color>

<Size>L</Size>

<Style>Hawaiian</Style>

<InStock>Y</InStock>

</Product>

 

 

Возможный эквивалентный текстовый документ выглядит так:

 

 

Red,L,Hawaiian,Y

 

 

В отличие от простого текстового документа, документ XML можно просмотреть

и определить значение каждого элемента. Но преимущество ли это? В конце

концов, файлы данных будут читать не люди, а машины. Что более эффективно

для машины: считывать данные или генерировать? Что лучше для ограниченной

полосы пропускания сети? Файл XML занимает в 6 раз больше места, чем

текстовый файл. В моих исследованиях файлы XML были в 45 раз больше, чем

такие же файлы с разделителями. Изза раздутой сущности XML поставщики

аппаратного обеспечения уже предлагают ускорители для компенсации этой

проблемы. Что еще хуже, появляется все больше и больше нестандартных

анализаторов XML, которые написаны для ?оптимизации? XML, но полностью

уничтожают всякую иллюзию о ?совместимости?. (Смотрите

http://techupdate.zdnet.com/techupdate/sto...2896005,00.html

.) Некоторые пытались доказать, что сжатие помогает компенсировать фактор

раздутости XML. Даже без детального анализа можно убедиться, что это полный

нонсенс. Если вы начинаете с файла, в 4 раза большего, чем его эквивалент,

и потом сжимаете его, то вам, возможно, посчастливится уменьшить его до

размера файла без XML, но что будет, если сжать этот самый файл без XML?

Кроме того, данный аргумент подразумевает, что сжатие является

?бесплатным?. Сжатие действительно увеличивает пропускную способность и

экономит дисковое пространство, но требует времени на обработку.

 

 

Облегчение коммуникации

 

 

Самодокументирующаяся сущность XML часто расценивается как помощь в

коммуникации между приложениями: мы можем посмотреть на файл XML и сделать

разумные предположения, так как значение данных основано на тэгах. Также

формат файла может меняться, не влияя на коммуникацию, потому что он

основан на тэгах, а не на расположении данных. Однако если тэги изменяются

или не подходят, то коммуникация будет прервана. Запомните хотя бы сейчас,

что компьютеры не умеют строить догадки.

 

 

Независимо от использования специальных средств коммуникация между

системами требует со?блюдения двух условий:

 

 

1. соглашение по тому, что будет отправляться (что обозначают данные);

 

 

2. соглашение по формату.

 

 

XML не меняет эти требования, и несмотря на уверения в обратном это не

упрощает дело. Для эффективной коммуникации между системами с помощью

текстового файла и отправитель, и получатель должны сначала согласовать,

какие элементы будут отправляться (это определяется по расширению файла и

означает, что значение каждого элемента уже определено) и позицию каждого

атрибута в файле. При использовании XML каждый элемент должен быть

определен и все соответствующие тэги должны быть согласованы заранее.

Заметьте, что самих тэгов недостаточно для верного описания данных и их

значения. Для этого необходимы бизнес?правила, которые управляют

использованием данных, пока не будет соз?дан универсальный стандарт,

который определяет соответствующий тэг для каждой возможной сущности,

которая может быть описана в документе XML (см.

http://www.well.com/~doctorow/metacrap.htm). То, что тэги XML расцениваются

как самоописывающиеся, приводит многих к дальнейшим ошибочным

предположениям, что определенные тэги будут правильно передавать точное

значение данных. В лучшем случае сами тэги передают примерное значение, а

этого недостаточно. В действительности было замечено, что тэги XML являются

метаданными, только если вы не понимаете саму суть метаданных (см.

http://www.tdan.com/i024hy01.htm).

 

 

Способ передачи данных не играет роли; усилия по правильной идентификации

данных и их значения остаются теми же. Единственное отличие, привносимое

XML, ? это дополнительная большая нагрузка на вашу систему.

 

 

Неструктурированные данные

 

 

Сама идея неструктурированных или полуструктурированных данных ? это

сочетание противоположностей. Без среды, в которой данные создаются,

изменяются и используются, сами данные ? всего лишь тарабарщина. Из?за

риска избыточности данные имеют определенное значение лишь в пределах

бизнес?правил, в которых они создаются и изменяются. И это не

преувеличение. Очень простой пример: данные '983779009?9937' не поддаются

расшифровке без правила, указывающего, что это верный номер определенной

запчасти. Другой пример, который часто приводят сторонники XML, ? это

книга. Но она состоит из частей, глав, абзацев, слов и букв, и все они

расставлены в определенном порядке, так что не говорите мне, что книга

неструктурированна!

 

 

Опять же, какое преимущество дает XML? Никакого. Данные по?прежнему должны

быть смоделированы, так как их значение должно быть сохранено, но XML по

своей сути иерархичен, что переносится и на данные. Было также замечено,

что XML ? это просто возврат к иерархическим базам данных прошлого.

Проблема заключается в том, что не все данные иерархичны. Реляционная

модель данных по своей сути не иерархична, но она безусловно способна

сохранять существующие иерархии. Они не являются нейтральными, поэтому

иерархия, которая хорошо работает в одном приложении или одном варианте

просмотра данных, будет абсолютно неправильной для других случаев, разрушая

независимость данных (см. http://www.geocities.com/tablizer/sets1.htm).

 

 

Именно здесь и содержится настоящая проблема. Не имеет значения, каким

большим и неэффективным может быть XML для передачи данных, но он абсолютно

ужасен в управлении данными. Иерархические базы данных вымерли, как

динозавры, десятилетия назад, и по простой причине: они негибки, и ими

очень трудно управлять.

 

 

Я могу понять, почему многие программисты, работающие с

объектно?ориентированными структурами, любят XML. И

объектно?ориентированные структуры, и XML иерархичны, и, если вы привыкли

мыслить в терминах деревьев и наследования, то множества могут показаться

вам абсолютно чуждыми. Это одна из основных трудностей

объектно?ориентированной парадигмы, а сейчас как раз то время, когда

профессионалы по управлению данными обучаются основам. Теория множеств и

логика предикатов (основы реляционной модели данных) оказались лучше

иерархических СУБД, основанных на теории графов. Почему же никто не

вспоминает о целостности данных, когда какой?нибудь программист кричит о

impedance mismatch, несоответствии между объектно?ориентированной

структурой и реляционными данными? Почему всегда автоматически

подразумевается, что ?ошибка? находится в области технологий баз данных?

(См. http://www.geocities.com/tablizer/oopbad.htm.)

 

 

Я добиваюсь от многих команд разработчиков, чтобы они не хранили XML в базе

данных как столбец varchar большой длины или text. Это превра?щает ее в не

более чем простое хранилище XML. Конечно, это нарушает один из принципов

устройства базы данных ? атомарность, или, в очень свободной трактовке, ?

один столбец, одно значение. Как может СУБД поддерживать какую?либо

целостность в столбце, содержащем XML? Как я узнаю, что разные строки XML,

хранящиеся в данной таблице, имеют какие?то отношения? Индексирование и

оптимизация по такой схеме невозможны. (На заметку: когда эта статья была

впервые опубликована, Microsoft как раз упомянула, что Yukon будет иметь

тип данных XML. Сейчас SQL Server 2005 практически готов, и в нем

планируется встроенная в базу данных поддержка XML. Независимо от того,

насколько хорошо Microsoft сможет реализовать сжатие и индексирование на

типе данных XML, он все равно подходит только для иерархических данных и не

годится для общего управления данными.)

 

 

Поставщики

 

 

Почему главные поставщики аппаратного и программного обеспечения полны

такого энтузиазма по поводу XML, если он настолько плох? Ниже представлено

несколько предположений.

 

 

1. Незнание. Отделы маркетинга управляют разработкой продукта и очень

хотят, чтобы он содержал какой?нибудь модный термин. Незнание частью

общества потребителей реального положения вещей позволяет маркетологам

увлечь нас разговорами.

 

 

2. Глупость. Технические ?эксперты? часто неграмотны, и, так как этому

нет никаких оправданий, я назову это глупостью. Я провел несколько часов на

последнем SQL PASS Summit, пытаясь найти хоть кого?то из команды SQL

Server, кто мог бы предоставить хотя бы одну хорошую причину для

использования XML. К концу диалога вокруг стола собралось как минимум пять

?экспертов?, и никто из них не мог привести разумных аргументов. Некоторые

ответы были просто шокирующими. Один из них утверждал, что самое большое

преимущество XML в том, что программисты могут легко подстраивать базу

данных под изменяю?щиеся требования, ?загружая? столбцы с множе?ством

атрибутов, чего база данных сделать не может! Здесь я понял, что зря трачу

время. Через два часа я покинул их с нарастающим чувством тревоги за

будущее SQL Server. Уверен, что они были рады моему уходу, так как смогли

вернуться в свою фантастическую XML?нирвану. Вместо того чтобы предпринять

какие?либо шаги для более глубокой реализации реляционной модели, они

гоняются за своими хвостами, пытаясь внедрить неудачную идею ушедших

десятилетий.

 

 

3. Жадность. Недавно я прочитал статью, превозносящую возможности XML.

По мнению автора, компании полагают, что ?XML улучшит их информационные

возможности, но также это приведет к необходимости обновления основных

систем? (http://www.dbta.com/frontpage_archives/9?03.html). Примечательно,

что он не уточняет, как именно XML ?улучшит? чьи?либо возможности, кроме

благосостояния поставщиков программного и аппаратного обеспечения.

 

 

Вы должны иметь в виду, что основные поставщики необязательно ставят именно

ваши интересы во главу угла. Я уверен, что, когда XML признают плохой

идеей, вам помогут все исправить? за дополнительную плату.

 

 

Заключение

 

 

Не поддавайтесь расплывчатым речам и притягательной рекламе. Как

профессионалы по управлению данными, вы ответственны за безопасность данных

вашей компании и не можете эффективно выполнять свои обязанности, не зная

основ или игнорируя их. Прочитайте статьи ?An Introduction to Database

Management Systems? (Chris Date) и ?Practical Issues in Database

Management? (Fabian Pascal) и чувствуйте себя уверенно, основываясь на

известных принципах управления данными. Альтернатива? Можете тратить время,

пытаясь угнаться за последней причудой индустрии, отдавая деньги

поставщикам и консультантам на каждом круге этой гонки.

 

Источник не указываю, така как статья взята с внутренней корпоративной конференции

Ссылка на комментарий
Поделиться на другие сайты

Раньше бы мне эту статью. Когда я еще Web-программистом работал, начальник заставлял меня все данные хранить в XML-файлах. И как я не доказывал, что реляционные СУБД подходят для хранения и обработки данных гораздо лучше, чем XML-файлы, он не слушал, а обосновывал все тем, что читал в книжке...

 

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

 

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

Ссылка на комментарий
Поделиться на другие сайты

Заархивировано

Эта тема находится в архиве и закрыта для дальнейших ответов.

×
×
  • Создать...