[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Shredding XML

  • From: "Michael Sokolov" <sokolov@ifactory.com>
  • To: "'Fraser Goffin'" <goffinf@googlemail.com>, <xml-dev@l...>
  • Date: Thu, 29 Oct 2009 22:41:32 -0400

RE:  Shredding XML
I spent a little while evaluating DB-2 and Oracle XQuery implementations -
didn't go so far as to implement a full-blown system though, I guess because
nobody was holding a gun to my head.  

The whole automated shredding approach strikes me as totally unworkable for
data with any complexity (think about David Lee's 80 table joins), and
unneccessary for simple data, where you might as well map by hand.  One
complication is that a schema is absolutely required, and if the schema
changes, you need to re-run the entire table generation process.  When I
checked, it was looking like it could be quite complex to retain data in
such a case: there didn't seem to be the ability to generate incremental
schema change operations, so probably it would be necessary to migrate data
from an old set of tables to a new set (with the same names!).

Then I considered the approach of storing an XML blob or two attached to a
metatdata record.  I could tell it would have been possible to implement,
and we probably could have gotten it working with some reasonable
computational efficiency in the end system.  However the programming
environment was looking very hostile: there are uncomfortable lexical issues
that arise when embedding XQuery in SQL or vice versa, and the idea of
passing values back and forth between the two different type systems was
making me uneasy.  I also found that the full text support (which for me is
absolutely critical) in DB-2 was lacking - when I checked they were in the
midst of a transition from an older, imperfect but functioning system to a
newer, but less functional one; the situation with full text is probably
better in Oracle; I didn't dig deep enough to find out details.

It does sound as if your data may be more record-oriented than mine, which
is almost always documents written in English or some natural language, with
tagging to make it at least somewhat machine-friendly.  So, as Michael Kay
said, if it's *already* record-oriented data that has just been wrapped up
in angle brackets, you might not run into these problems.

-Mike


> -----Original Message-----
> From: Fraser Goffin [mailto:goffinf@googlemail.com] 
> Sent: Thursday, October 29, 2009 5:20 PM
> To: xml-dev@lists.xml.org
> Subject:  Shredding XML
> 
> This list has been unusually quiet of late so I thought it 
> might be an opportune moment to ask for opinions on the 
> subject of decomposing XML into relational databases, often 
> referred to as 'shredding'.
> 
> My particular interest is related to some work I'm currently 
> engaged in. The basics are we receive XML messages from an 
> external trading partner and process those messages, 
> enriching and routing to a number of internal subscriber 
> applications. One of these applications is MI and the deal 
> here is that they want the data to been put into a relational 
> database so that they can create a number of interfaces 
> 'files' which are sent to still more applications.
> 
> Whilst I would like to consider a pure XML database or even 
> use some of the XML features that are increasingly prevalent 
> in mainstream DB vendor products, clearly putting data into a 
> 'staging' database is one thing, but the capabilities and 
> competances of the applications and application programmers 
> who want to retrieve it is a key factor. So, for the 
> immediate term I might be stuck (if thats fair - probably 
> not) with relational.
> 
> So to better inform myself and maybe help the debate along 
> internally, I am interested in anyone else experience good 
> and bad, of shredding XML data, pitfalls, things to be aware 
> of, good approaches, when to really not do it. All thoughts 
> are welcome.
> 
> I find it intersting the some of the 'big boys' are at least 
> giving the appearance of providing first-class support for 
> XML both in terms of storage options and manipulation 
> capability. IBM for example has pureXML. I haven't used these 
> enough to know if they're just a thin veneer of whether they 
> have real substance and depth, so again your experiences are welcome.
> 
> Regards
> 
> Fraser,
> 
> ______________________________________________________________
> _________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by 
> OASIS to support XML implementation and development. To 
> minimize spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org List archive: 
> http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 
> 


  • References:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.