Re: Modeling Data for XML instead of SQL-DBMS

From: dawn <dawnwolthuis_at_gmail.com>
Date: 25 Oct 2006 05:57:15 -0700
Message-ID: <1161781034.795877.88480_at_i3g2000cwc.googlegroups.com>


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 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 Received on Wed Oct 25 2006 - 14:57:15 CEST

Original text of this message