我在DoxDB上採用了一種稍微不同的方法,因爲我選擇了JSON而不是XML作爲文檔結構,儘管我認爲它與您所需要的沒有太大差別(事實上,當我開始使用它時XML首先)。
TL; DR版本
使用LOB存儲您的XML內容。您的JPA只有一個@Lob
註釋,您可以加載內容。
使用XSD驗證您的數據來自您的傳輸使用Marshaller
,它通過您的@WebService調用,它提供了CRUDL方法在JPA實體中處理作爲lob的條目。
然後調整安全性和性能。
更多細節
需要注意的是我自己不映射將JSON/XML到數據庫中的字段和表格,而是我有一個表,一個「SCHEMANAME」欄,LOB以及一些ID(雖然事情目前它有一些額外的審覈字段和只執行邏輯刪除的字段)。我搜索了Stack Overflow,並且似乎共識是,如果數據相似,最好有一個大的表對比許多小表,而且JPA不支持動態表名。
取代JAX-WS,我選擇了JAX-RS(REST API),但這只是一個傳輸層,您可以根據自己的需要選擇其中之一。在那一層,我實現了一個與JPA交互的CRUDL API。你可以在JAX-RS中傳遞XML,如果你不想,你不需要去WSDL。
最初的表現措施並不算太壞。加載100,000行花了大約一分鐘,做單行檢索仍然在亞秒。檢索和渲染100,000行大約需要5秒鐘。當然,它沒有科學,我懷疑它會在現實生活中產生這樣的性能,由於XA事務,分佈式友好,安全性和傳遞性依賴性很小而導致大量負載。
我早期做出的一個體繫結構決策是DoxDB不會對數據庫執行搜索,而是將作業傳遞到ElasticSearch,該ElasticSearch通過其REST API調用,而不是嵌入到應用程序中(這將涉及到他們的依賴關係)。這是供應商的具體情況,但目前我還沒有找到更好的選擇。
我想到的是同樣的東西 - 關於保留JPA和WS的存根是絕對正確的。我也在檢查從XSD文件生成表創建腳本的工具,但沒有一個真正證明自己創建它們太不同,至少我有更多的控制權。我的問題是,Web服務請求/響應XSD具有太多多次發生的節點,並且有些節點深度很深,所以很難對所有這些關係進行建模,因爲表列不能是表本身。我需要爲所有多個發生節點定義單獨的表並添加適當的鍵列 – GTware 2013-05-07 19:55:58