KuteLuvr (kuteluvr) wrote,

  • Mood:

Structured Data

I have one request of all of the developers out there:
Please do not put structured data into a single database field!
I'm dealing with this application that stores it's data as XML. It stores this resulting XML data as one large string in an Oracle CLOB field. This is an evil, evil, evil combination. Now, imagine trying to do a query where you want to see if a single element of the XML contains a value. Now do that over 750,000 records. OUCH.

XML is great for data exchange... it's great for passing off to an XSLT parser... sure. Those are all wonderful uses of XML. However, it's not so great for data storage, especially when the XML datasets become extremely large. If you're feeling uber-trendy and just HAVE to use XML, then feel free to do it OUTSIDE of the data tier. You say you want the ability to store flexible data? No problem! Make your DB schema metadata based. You can accomidate anything in perfectly discrete compartments. You can manipulate it any way you want. And when you need it in the application, build a reusable formatter in your access layer that will create the nice pretty XML you're looking for from the metadata structure. Then you can do whatever you want with it. Need to support a new XML schema? NO PROBLEM! You can already handle it! Great Job!

...but until I can rewrite this POS crap I have to deal with, I'm left with essentially doing LIKE clauses on the data in the DB, or sucking it all out and loading it into an actual XML parser to get the real data through the XPath.

This is lame.
Tags: work
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded