XML數據庫探討2

同樣的，對於XML數據庫（就是native-XML數據庫，以下簡稱XMLDB）來說也有很多難於跨越的鴻溝,導致了經過這麼多年的發展，最終卻一直沒有壯大。參考網站：http://www-900.ibm.com/developerWorks/cn/xml/x-xdata/part5/index.shtml#1 的敘述，關於XMLDB現在有以下一些問題：（以下是引用的內容）

存儲
在資源庫中存儲信息很簡單。如果希望存儲的信息已經是 XML 格式，那麼可以直接把它添加進資源庫。這也許聽起來不錯。畢竟在不斷創新的 Web 服務世界中，將要到來的多數信息將使用嵌入在 SOAP 消息中的 XML 片段格式。然而，把 XML 文檔分解並保存到關係數據庫一點也不困難；當開始查看希望支持的其它功能時，這種作法會有一些好處。同樣許多本 Native-XML 數據庫供應商所鼓吹的一個好處是 Native-XML 數據庫能夠存儲和查詢異種的文檔結構。再說，對於結構化數據問題在於：您真的希望信息的結構千變萬化嗎？對於使用 XML 文檔時具有的這種優勢，當使用結構化數據時就算不上是一種優勢了。

檢索
初看上去，從 Native-XML 數據庫檢索信息似乎也是一個好處：以信息的原始 XML 格式檢索它，而不需任何附加的編碼，並且可以使信息以一定的樣式顯示。然而，結構化數據檢索的性質使得這種明顯的優勢實際上變成了劣勢。如果信息更新量巨大（例如，接收單個數兆字節大小 XML 文檔的股票系統的夜間更新），一些 Native-XML 平臺需要從數據庫返回整個文檔 — 即使您只對文檔的很小一部分感興趣（譬如某個特定股票的變化過程）。 其它 Native-XML 平臺在將 XML 文檔保存到資源庫之前進行分解，但是如果具有複雜的文檔結構（正如許多結構化 XML 文檔傾向於具有這種結構）時，這樣做就顯得有點笨拙。無論如何，許多關係數據庫供應商目前正在實現瘦 XML 序列化器包裝器以便支持在需要時從關係數據生成 XML 文檔。這使得程序員可以容易地獲得完成特定任務所恰好需要的信息，這些信息具有某種格式，這種格式具有所需樣式、或者可以發送給其它能識別 XML 的目標。

搜索
搜索 Native-XML 數據庫有兩種常規解決方法可用，選取哪種取決於數據庫供應商。一些 Native-XML 數據庫需要選擇哪些元素或屬性用於索引，如同在關係數據庫裏選擇哪些列用於索引。然後，這個信息被用於建立索引，以便搜索機制能用來快速定位相匹配的文檔。在文檔被添加到資源庫時，其它 Native-XML 數據庫就是對文檔內的所有信息建索引，可以想象這將導致存儲空間需求飛速上升（想象一下在關係數據庫中對所有列建索引！）。由於這些數據庫以文檔爲中心的性質，搜索將返回一組 XML 文檔；然後如有必要，調用程序還得對這些文檔做進一步處理。 很遺憾的是，這意味着更復雜的搜索，是很不方便的。例如，要找出那個對某一特定部分提交最高訂單的顧客，以爲在中間環節要處理很多事情。在指向關係方面 Native-XML 數據庫做的也不好。結果是，如果數據結構不是純粹層次結構的，則對您而言，Native-XML 數據庫就不是恰當的解決方案。大多數 Native-XML 數據庫具有這一功效強大的特性 — 執行完善的全文搜索的能力，包括整個同義字支持、字根（匹配一個字的所有形式：現在時、過去時和進行時）以及相近搜索（DTD NEAR XML Schema）。此外，在使用傳統文檔時，這些特性是不可缺少的，其中上下文在含意上起着重要的作用，而當使用結構化數據時，就遠沒有那麼重要了。

聚合
使用關係數據工作時，聚合是所需要的最重要功能之一，事實上它處於聯機分析處理的核心（OLAP）。Native-XML 數據庫在執行聚合任務方面表現得特別差。因爲信息要麼被保持在文檔這一層，要麼一般被分割成節點，所以把信息彙集起來以及集中處理它（求和、平均數等等）就很困難，此外，還必須在中間環節增加附加代碼。如果結構化數據應用程序需要任何一種分析處理 — 我打賭它會需要 — Native-XML 數據庫將會使您失望。