pgxml?
А надо ли?Во-первых, XML-документы бывают самые разные. Простое деление документов на data-oriented и document-oriented даёт представление о том, что лучше - XED (XML Enabled Database) или NXD (Native XML Database). Рассуждения об этом - см. заметку http://www.xml.com/pub/a/2001/10/24/follow-yr-nose.html (перевод тут: http://xmlhack.ru/texts/followNose/followNose.html). Вкратце, очень много соображений в пользу РСУБД с поддержкой XML (data-oriented документы достаточно просто ложатся на реляционную модель, т.е. можно осуществить преобразование и "разложить" данные по группе таблиц), document-oriented документы тоже предпочтительнее хранить в XED, если в схеме можно выделить отдельно стоящие метаданные (в этом случае XED достаточно проиндексировать только этот кусок документа), если же надо делать сложные запросы к контенту, то XED-у придётся туго, ибо не совсем ясно, как быть с контентом (структура document-oriented документов может сильно меняться при переходе от одного к другому)... Таким образом, плавно перетекаем к "во-вторых" - многое зависит от того, что с данными надо делать (какие запросы строить)... поддержка не только XPath, но и XUpdate может дать многое В-третьих, (и, как говорится, the last but not the least), если уже создана большая база, поддерживаемая РСУБД, и есть какое-то кол-во приложений с ней работающих - переход на NXD может оказаться равносильным пожару. Так что, мотивация есть. Postgres'у нужно уметь работать с XML.
Как хранить?Видятся следующие пути хранения: 1. BLOB-ом. "Топорный" метод, но в тривиальных случаях может выручить (не нужно мучиться с разбором дерева и т.д.). XPath "эмулируется" рег. выражениями. Уже реализовано (contrib/xml, contrib/xml2) 2. "Раскладываем" документ по реляционным таблицам. Подходит в случае, когда схема группы документов "достаточно строгая" (а ведь её может и не быть вообще...), документы вида data-oriented. Плюсы очевидны: с данными работать достаточно просто, все механизмы (О)РСУБД в наших руках. Минусы - а) чтобы "собрать" обратно документ, надо сделать кучу join-ов; б) большая часть таблиц может "пустовать" для большой части документов; в) не все XML-схемы легко "нормализуются" в реляционные (см., напр., http://www.xml.com/pub/a/2001/05/09/dtdtodbs.html), данный процесс может привести к появлению огромного числа таблиц, многие из которых будут очень "широкими". 3. Поддержка в ОРСУБД специального типа - XMLTYPE. Т.е. при определении таблицы мы можем сказать, что некоторый столбец имеет данный тип. Это означает что в любой строке таблицы в данном столбце будет содержаться целый XML-документ. Плюсы подхода: нет (явной) нужды создавать большое количество таблиц; нет требования в высокой строгости схемы (т.е. данные могут быть действительно полуструктурированными, схемы может не быть вообще); ... . Минусы: совершенно неясно пока, как облегчить задачу "доставания" части XML-документа, как будет работать JOIN по значению какого-либо атрибута XML-документа и, скажем, столбца другой таблицы; какие операции с этим типом определять (по идее, они описаны в SQL:200n, часть 14); ... ; идеологическая проблема - целый документ в одном столбце, т.е. какая уж там NF1... Кроме того, в некоторых случаях, возможно, вообще не надо заморачиваться. Например, если уже имеется реляционная база и стоит задача экспорта данных в формате XML (вообще говоря, это подмножество случая 2) - достаточно иметь инструмент для преобразования обычного result set'а в XML. Пример реализации - SELECT FOR XML у Microsoft (http://msdn.microsoft.com/library/defaul ... ry/en-us/xmlsql/ac_openxml_759d.asp).
useful links[PATCHES] SQL/XML publishing function experimental patch: 1: http://www.pgsql.ru/db/mw/msg.html?mid=2096818 2: http://archives.postgresql.org/pgsql-patches/2006-06/msg00147.php [HACKERS] SQL/XML public functions documentation for PostgreSQL 8.2: http://candle.pha.pa.us/mhonarc/patches_hold/msg00106.html [HACKERS] SQL/XML extension: http://candle.pha.pa.us/mhonarc/patches_hold/msg00119.html It's necessary to make grammar hacks... : http://archives.postgresql.org/pgsql-hackers/2004-01/msg00758.php http://archives.postgresql.org/pgsql-hackers/2004-01/thrd2.php#00758 SQL/XML extension (research): http://archives.postgresql.org/pgsql-hackers/2005-08/msg00576.php SQL/XML examples : http://archives.postgresql.org/pgsql-hackers/2003-03/threads.php#01183 quote:
IIRC, Peter Eisentraut noted a while ago that implementing the SQL/XML functions properly would require building them into the postgresql parser as special cases.
Requests: http://archives.postgresql.org/pgsql-novice/2005-09/msg00140.php
GiST home: http://gist.cs.berkeley.edu/ How to write GiST ext: http://www.sai.msu.su/~megera/postgres/talks/gist_tutorial.html
Indexing of large XML docsXISS system (Li, Moon - advanced interval indexes) http://www.cs.arizona.edu/xiss/ MASS (prefix indexes) http://davis.wpi.edu/dsrg/vamana/WebPages/Publication.html
XML DBMSOverview: http://www.rpbourret.com/xml/ProdsNative.htm Sedna: http://www.modis.ispras.ru/Development/sedna.htm eXist: http://exist.sourceforge.net/
MS SQL(VLDB2005) XQuery Implementation in a Relational Database System: http://www.informatik.uni-trier.de/~ley/db/conf/vldb/vldb2005.html#PalCSRSYTBBCK05 "SQL Server 2005's new XML data type is based on this standard." (http://www.stylusstudio.com/michael_rys.html) Michael Rys blog: http://sqljunkies.com/weblog/mrys/
Oraclehttp://www.oracle.com/technology/oramag/oracle/05-jul/o45php.html SQL 2003 Standard Support in Oracle Database 10g: http://www.oracle.com/technology/product ... on_development/pdf/SQL_2003_TWP.pdf [2002] SQL/XML is Making Good Progress A. Eisenberg, J. Melton: http://www.sigmod.org/sigmod/record/issues/0206/standard.pdf
DB2(from VLDB2005) Native XML Support in DB2 Universal Database: http://www.informatik.uni-trier.de/~ley/db/conf/vldb/vldb2005.html#NicolaL05 http://www-306.ibm.com/software/data/db2/extenders/xmlext/ 4612
|
