Re: Modeling Data for XML instead of SQL-DBMS
Date: Fri, 27 Oct 2006 14:01:46 +0200
Message-ID: <ehssfa$n4r$1_at_nntp.fujitsu-siemens.com>
dawn schrieb:
> Volker Hetzer wrote:
>> 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
>
> That is OK with me as long as I am also doing the database model from
> scratch as if there were no SQL. If I have no need to bring in 1NF (by
> traditional meanings) structures into my design, I would not want to
> design a data model with that approach and then have to convert,
> although that would be feasible.
Normal forms do not imply sql, they imply relational databases. In that case they are "best practice", i.e. what you want to hear.
>> 3) store it as native XML datatype in any modern database.
>
> My real issue is not in how to persist XML documents, but in how to
> model data for persistence using both old and new non-SQL-DBMS tools
> (that do not limit the designer to 1NF, nor introduce the SQL NULL for
> use with a 3VL, for example).
If persistence is your only issue, store them on the file system. If you are in love with a particular database, design one table with the full pathname as primary key and the contents as blob (Binary Large Object). Or as an XML datatype.
Please, please tell us about the *other* issues. We cannot give you reasonable advice otherwise.
For an ERD-model you don't need NULLs, you can work with defaults or you can work with lots more tables and substitute defaults at query time. Still, "best practice" for relational databases recommends normalisation.
>
>>> 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.
>
> Yes and 3NF is defined to require 1NF (which has been redefined over
> the years). I want to eliminate 1NF, while still concerning myself
> with issues of functional dependencies.
At which point you are leaving the "best practice" bit you are enquiring about.
> Perhaps the XML document distract you from underlying question I have.
> There are many terabytes of data in databases from software
> applications where a "standard" SQL-DBMS is not the software component
> used between the application a database. These are either old or new
> models as this approach pre-dates the relational model and is also at
> least one possibility for the future of software development.
Which approach to you /want/ to take?
We cannot give strong advice here because it depends on the usage
patterns, which you haven't told us yet.
> I'm looking for industry best practices for such. Two primary
> differentiators that I am using to test whether something is an
> SQL-DBMS or other (since most tools permit SQL queries) are 1) whether
> it is typical for developers to work with data in the form (formerly
> known as) 1NF or not and 2) whether nulls are logically values (such as
> empty set) or represent the lack of a value. If the DBMS has both a
> value-less NULL and an empty set "null" (e.g. empty string) then they
> can still fall in this category. If a DBMS meets both the non-1NF and
> 2VL tests, then it is in my not-SQL-DBMS category even if it has an SQL
> implementation. I suspect we will get a name for these that is better
> than non-SQL-DBMS in the future, other than the typical marketing spin
> of today where these are typically referred to as "embedded databases"
> (even when employed for ERP solutions).
In my humble opinion "the" "industry" generally accepts NULLs and finds
the resulting problems somehow manageable.
However, NULLs are entirely optional and neither the relational model nor
SQL enforces them. It just takes a bit of discipline when designing the
tables and queries.
Lots of Greetings!
Volker
-- For email replies, please substitute the obvious.Received on Fri Oct 27 2006 - 14:01:46 CEST