Re: Modeling Data for XML instead of SQL-DBMS

From: dawn <dawnwolthuis_at_gmail.com>
Date: 26 Oct 2006 14:04:14 -0700
Message-ID: <1161896654.848373.205260_at_m73g2000cwd.googlegroups.com>


David Cressey wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1161894159.173333.173510_at_m7g2000cwm.googlegroups.com...
> > David Cressey wrote:
> > > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > > news:1161863476.352229.292860_at_i42g2000cwa.googlegroups.com...
> > > > David Cressey wrote:
> > > > > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > > > > news:1161809096.025872.244220_at_i42g2000cwa.googlegroups.com...
> > > > > > David Cressey wrote:
> > > > > > > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > > > > > > news:1161778688.975810.241810_at_i3g2000cwc.googlegroups.com...
> > > > > > > > David Cressey wrote:
> > > > > > > > > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > > > > > > > > news:1161775082.641612.23070_at_i3g2000cwc.googlegroups.com...
> > > > > > > > > > mAsterdam wrote:
> > > > > > > > > > > <Annotations>
> > > > > > > > > > >
> > > > > > > > > > > dawn wrote:
> > > > > > > > > > > > If working on a software project where all data are
> > > persisted
> > > > > > > > > > > /persisted/
> > > > > > > > > > >
> > > > > > > > > > > Ah, we are talking software development on an island,
> not
> > > > > > > > > > > about shared data.
> > > > > > > > > >
> > > > > > > > > > Sure, we could assume that if it helps.
> > > > > > > > >
> > > > > > > > > If we assume that, then database theory becomes irrelevant.
> > > > > > > >
> > > > > > > > Your definition of database would be what then? --dawn
> > > > > > > >
> > > > > > > There's no need for me to post yet another definition of
> database in
> > > > > this
> > > > > > > ng. My
> > > > > > > previous comment stands.
> > > > > >
> > > > > > OK, I looked up what I think is the most recent cdt glossary and
> it
> > > has
> > > > > > this entry:
> > > > > > <glossaryEntry>
> > > > > > [Database]
> > > > > > "A logically coherent collection of related real-world data
> > > > > > assembled for a specific purpose." -- rephrased from
> > > > > > "Fundamentals of Database Systems", Elmasri & Navathe.
> > > > > >
> > > > > > 1. Deluxe file system
> > > > > > 2. Shared databank (E. Codd)
> > > > > >
> > > > > > </glossaryEntry>
> > > > > >
> > > > > > So, I will agree that if you equate "shared databank" with
> "database"
> > > > > > and you interpret shared to mean that it is shared by multiple
> > > > > > companies (rather than simply multiple people or processes), then
> > > > > > perhaps by def 2 this is not a database. But by pretty much any
> other
> > > > > > definition this is a database. Given that, I would suggest it is
> > > > > > definitely relevant to databases and data modeling.
> Agreed? --dawn
> > > > > >
> > > > >
> > > > > I don't recall ever saying that it had to be shared among multiple
> > > > > companies.
> > > > >
> > > > > I do think that, in order for database theory to be relevant, it has
> to
> > > be
> > > > > shared among multiple partners. Those partners could all be in the
> same
> > > > > company, or they could be in different companies. They could be
> using
> > > the
> > > > > same programming language, or different programming languages. They
> > > could
> > > > > be accountable to the same management, or they could be accountable
> to
> > > > > different managements. The point is that they are sharing data, and
> > > they
> > > > > aren't all under "our control" (to quote the phrase you used
> elsewhere
> > > in
> > > > > this discussion.)
> > > >
> > > > So, think of this as a database that is shared in a way that it IS all
> > > > under our control. Does that help clarify the question? --dawn
> > > >
> > >
> > > As far as I'm concerned, there was nothing to clear up, except perhaps
> for
> > > the word "our".
> > >
> > > If the data and its model is all under YOUR control, then database
> theory is
> > > irrelevant to your question.
> > > My prior comment stands.
> > >
> > > If it's all under MY control, you can bet it's not going to be stored
> in
> > > XML.
> >
> > Laughing. Are you saying that only people using SQL-DBMS tools get to
> > claim there is or could be any theory associated with their efforts?
> > If that is your position, are there at least industry "best practices"?
> > If so, any clues where I might find them? --dawn
> >

>

> No, I'm not claiming any such thing. I'm just claiming that database theory
> is irrelevant to YOUR efforts.

Why? Should I stop employing normalization-ish (sans 1NF) related to functional dependencies? That aspect of relational theory is relevant to my efforts even when employing a database that many would say is not relational (most still seem to advertise as relational or sometimes post-relational).

> As far as industry "best practices" and my own "best practices" goes,
> sometimes I agree with the consensus of the industry, and sometimes I don't.

Yes, as (you can tell) is the case for me as well. I can typically be informed by it, however, even when I disagree. I think it is an unfortunate gap that there seems to be little written on best practices in this area. I'll try to collect some from practitioners. Cheers! --dawn Received on Thu Oct 26 2006 - 23:04:14 CEST

Original text of this message