Re: Modeling Data for XML instead of SQL-DBMS
Date: Thu, 26 Oct 2006 15:49:46 +0200
Message-ID: <ehqedq$3o7$1_at_nntp.fujitsu-siemens.com>
dawn schrieb:
> 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.
When I'm talking about the database I'm talking about the type of database generally accepted as "database" in this group. I suggest you adapt to the terminology in this group too, for discussions within this group.
> 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.
No.
There are three ways, depending on what you want to do:
1) Understand the XML contents and do a database model from scratch as if
there was no XML
2) Translate into a simple tree like ERD
3) store it as native XML datatype in any modern database.
> 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?
The industry best practice is to to one of the three things above.
Point one usually implies at least N3.
>> 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.
This doesn't change that "most modern databases..." see the bit of mine you quoted.
>
>> 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.
Not to me, sorry.
If there is no need to have the data persist, theory and practice yields the suggestion not to put it into a database at all. That is so, because usually the effort to load and unload it outweigh any benefits from faster querying for example.
Lots of Greetings!
Volker
-- For email replies, please substitute the obvious.Received on Thu Oct 26 2006 - 15:49:46 CEST