Re: Modeling Data for XML instead of SQL-DBMS

Volker Hetzer wrote:
> dawn schrieb:
> > 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?
> Depends on what came first. If you've got a nice XML model, you can probably
> model it straight a way as a bunch of one to many or whatever relations in the
> database.

Using a broad definition of "database" the XML documents, in this case, are the database. They are going to come first and there is no SQL-DBMS as a target. So, the question is what theory and practical tips are there from the past 50 years of computing to help build a good data model for this XML "database' or data repository, if you prefer.

> Truly nested stuff <node><node><node></node></node></node> will
> require some thought but it's definitely and easily doable.

Yes, that is the thought process I want to tap into. What are the industry best practices for designing data for a non-1NF repository such as these XML documents?

> On the other hand, if you've got the database model first,

This will be my "database" model.

> you can run
> into trouble because the relational model allows more than a strict hierarchy.
> In this case your XML equivalent may have to look like two collections, one
> for the entities and one for the relations. Very ugly and not well suited to
> searching and scanning.

Definitely not necessary in this case.

> Most modern databases can store XML as it is, either as blob or in separate
> tables.

Think of the XML docs as a collection that constitutes a base of data for this app.

> If all you're concerned is the amount of XML data but would like
> to stay as XML'ish as possible (i.e. using xpath/xquery only not on the doc
> but on the database), that's the way I'd go.

I'm looking for the theory and practice that would yield the best results for the design of this data repository if it is exclusively in XML documents, with web services taking it anywhere else it needs to be, but with no requirement to ever be persisted by way of a SQL-DBMS, for example. I hope that makes some sense. Thanks. --dawn

> Lots of Greetings!
> Volker
> --
> For email replies, please substitute the obvious.
Received on Wed Oct 25 2006 - 18:12:15 CEST