Re: Modeling Data for XML instead of SQL-DBMS

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. Truly nested stuff <node><node><node></node></node></node> will require some thought but it's definitely and easily doable.

On the other hand, if you've got the database model first, 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.

Most modern databases can store XML as it is, either as blob or in separate tables. 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.

Lots of Greetings!
Volker

-- 
For email replies, please substitute the obvious.