20091030002408.GW5522@w3.org" type="cite">--> Liam Says ... Yes, this is what I recommended in a book on the subject, years ago, and is what generally works the best. I was only slightly serious when I said it was "useless". I have implemented quite functional and useful systems using this approach (storing xml as a blob field). It works and performs extremely well ... as long as you don't try to use the blob field in an SQL Query ... Rather, load the field as a blob into the application memory and perform your XML operations there. I have found that this can perform 100's (or more) of times more efficiently then performing similar operations on the server using relational data ... providing you have enough memory and the processing is localized. In one example, I had an xml schema with about 50 distinct elements. We did an experiment of shredding this into relational data, which turned into about 80 tables. Performing joins across 80 tables was dismal, even when done as a stored procedure (in an enterprise DB no less). However the analogous operation of loading the entire "blob" into memory on the client, then parsing it as XML then using java XML operations on the data (and in this case we were writing it back out) performed vastly (100x+) better and was much simpler to code. I do recommend this approach if your xml data is localized, and can fit into memory, and doesn't need to be deeply queried from SQL. You do gain some advantages of a relational DB - namely the consistency of storage, backups and data management. And you can tell everyone "Its in the database" ... (then duck). -David lee dlee@calldei.com www.xmlsh.org |