Re: Modeling Data for XML instead of SQL-DBMS

From: JOG <jog_at_cs.nott.ac.uk>
Date: 25 Oct 2006 06:16:47 -0700
Message-ID: <1161782207.218775.17180_at_m73g2000cwd.googlegroups.com>


dawn wrote:
> JOG wrote:
> > dawn wrote:
> > > If working on a software project where all data are persisted in XML
> > > documents and not in an SQL-DBMS, the tools would not require that the
> > > data model be in 1NF or the use of the SQL NULL.
> > >
> > > How would an excellent logical data model designed for this XML
> > > implementation differ from the corresponding data model developed for
> > > an SQL-DBMS? What would be some best practices for modeling data in
> > > this environment?
> > >
> > > I'm guessing some will think that the exact same logical data model
> > > would be appropriate for both targets, but hopefully many will agree
> > > that it is unlikely that the best implemented data model would be
> > > identical in each environment. In that case, what would the
> > > differences be? What best practices would apply to data modeling for
> > > XML documents compared to data modeling for a SQL-DBMS?
> > >
> > > Thanks. --dawn
> >
> > I persist my data using the excellent C++ boost::serialize libraries,
> > when I am working on such an 'island'. And in that case your
> > organization of data can follow recommended OO design.
>
> Yes, sure, and once serialized, I can use the same language to get it
> back as long as I can find it. So, there are best practices for
> SQL-DBMS's and best practices for objects, but I'm looking for a way to
> capture the best practices for an approach used often that is neither
> of these.

If it is not shared data, and it is not code-specific data... what is it? I don't see any middle ground there at the moment?

> If it had a great name, perhaps it would take me so may
> years to get this question asked successfully ;-)
>
> > Using XML for
> > the sake of fashion,
>
> Not doin' that. I'm using it in order to see if I can get this
> question asked in an acceptable way. It isn't easy, ya know. And I
> suspect that you know that I have a legitimate question, so feel free
> to help me ask it.
>
> > as all efficient coders know, does nothing but add
> > processor cycles to parse the unwieldly crap.
>
> I hear you, brother. That does not negate the question, however.
>
> > If nothing else this highlights why codd named his paper for "large
> > SHARED databanks". If your data isn't shared, and you are sure you are
> > never, ever, ever going to use it in a different way then I guess you
> > don't have to worry about query bias. As a caveat however, I'd say that
> > situation is going to be pretty damn rare.
>
> And yet such data structures are designed every day by developers
> around the globe, often sharing none of their lessons learned because
> it is in the underground non-SQL-DBMS world where few dare speak
> outloud about what they are doing ;-) Other than telling them to stop
> using such tools for their databases, what would be some best practices
> for such data design? thanks. --dawn

I was actually trying to answer your question dawn. Perhaps I didn't express it sufficiently. More succinctly I was trying to say - if one is not concerned with Query Bias why would one be concerned with such things as normalization at all? Persist your data in the way that is most efficient to get it back into RAM in the structure your program requires it. Received on Wed Oct 25 2006 - 15:16:47 CEST

Original text of this message