БД и XML

Ижевский Виталий Григорьевич

Спецвыпуск: Хакер, номер #052, стр. 052-066-2

И как же быть, если большинство клиент-серверных БД разрабатывается именно под InterBase? Надо внести возможность обработки XML в эту СУБД с помощью механизма UDF (User Defined Functions). Покажу жизненный пример реализации, который используется на практике.

Итак, преамбула: существует сложная структура данных, например, информация, в которой используется адрес (данные о недвижимости). То есть адрес дома, владелец, площадь и т.д. Строка адреса примерно такая: Россия, Москва, ул. им. Заезда 20 Партии, д. 24, кв. 15. Наиболее простое решение – создание нескольких таблиц с отношением один-ко-многим. Например:

Но иногда бывают и такие адреса: Россия, Московская обл., заправка 120 км Новопростоквашинского шоссе, постройка амбар №2. И тут начинается… Простая, на первый взгляд, проблема превращается в десятки таблиц-справочников, пишутся сложные запросы с разными Joinа’ми. Давай пересмотрим решение. Реально в таблице country могут быть две-три записи, в других (region, city) - несколько десятков или сотен. Фактически база данных может занимать 1 Гб, а данные об адресах - 200 Кб. Так вот, данные об адресах можно сохранять и отдельно от базы, например, в XML-формате:

Тогда первая структура БД превращается в такую:

Как видишь, дышать стало легче: от строки адреса остался только идентификатор idXML. Но как получить нужные данные, как предоставить пользователю не число-идентификатор, а действительно строку адреса "Россия, Московская обл., заправка 120 км Новопростоквашинского шоссе, постройка амбар"? В этом тебе поможет Xpath-запрос. Например, такой:

//*[@ID=3]/ancestor-or-self::*/Название/concat(text(),” ”,local-name(..),” ”)

Реализовать поиск по XML-файлу и передачу нужных данных серверу InterBase, а потом и пользователю можно через упомянутый механизм UDF.

Выбор парсера

Для разбора XML-файлов важен выбор парсеров, которых существует целое семейство. Наиболее известные - это libxml и msxml. Кто хочет использовать Linux, тот, конечно, будет использовать libxml. Но при первом беглом взгляде на документацию много кому становится плохо: больше двух тысяч функций лишь в одной библиотеке libxml2 (последней версии libxml). Разобраться в них будет очень и очень непросто. Дело в том, что разработчики придерживались всех стандартов и правил W3C, поэтому libxml является в некотором роде эталоном (правда, тяжеловатым).

С MSXML намного проще: все упаковано в красивые COM-объекты, есть строгая иерархия, прекрасная документация с примерами, все в духе Micrisoft’а. Изучить MSXML и начать работать с ним можно практически сразу. Но, как всегда, со стандартами у Microsoft плоховато. Например, в MSXML было заявлено о полной поддержке XPath 1.0 и о частичной поддержке Xpath 2.0, но XPath 1.0 не всегда выдавал то, что нужно, а XPath 2.0 вообще не видно. И со скоростью в MSXML всегда было плоховато.

Но с выходом MSXML v.4 SP2 библиотека стала работать быстрее (разработчики гарантировали четырехразовый прирост производительности и не наврали). Даже быстрее libxml2 (примерно в полтора раза), а скорость играет большую роль. При небольших объемах выборки (выборка меньше тысячи) SQL c UDF работает без сомнений быстрее, чем компиляция и выполнение SQL-запроса с пяти-шести таблиц, но, конечно, при условии что XML имеет разумный предел (2-3 Мб). При больших объемах (выборка 3-4 тысячи и более) ситуация меняется на противоположную, но сложно представить себе человека, способного просмотреть 5000 записей за раз. Таким образом, при всех недостатках MSXML можно сказать, что Microsoft сделала хороший продукт, поэтому для решения описанной выше проблемы будем использовать именно его.