Re: Modeling Data for XML instead of SQL-DBMS

JOG wrote:
> 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 would call it shared data, but for this purpose let's say that it is data that is accessed by various software written in different languages, but all written by or licensed by the same company. It is data accessed by one company, multiple languages.

> I don't see any middle ground there at the moment?

A csv spreadsheet would an example of data that can be accessed via many different languages.

> > 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?

One would still be concerned with maintainability and best practices, right?

> Persist your data in the way that is
> most efficient to get it back into RAM in the structure your program
> requires it.

Think of multiple programs, multiple apps, but a single company. Thanks. --dawn Received on Wed Oct 25 2006 - 16:53:19 CEST