dwolt_at_iserv.net (Dawn M. Wolthuis) wrote in message news:<6db906b2.0310100813.65b872d8_at_posting.google.com>...
> Thank you, Seun, for asking your question with a bit of logic and not
> gut-reaction emotional baggage (and for also asking a question of me
> off-list so I could ramble). I'll try to make this more suscinct.
>
> First of all, I have read Codd's 1970 & 1974 ACM papers, as well as
> his "The Relational Model for Database Management, Version 2" book. I
> have also read several books by Chris Date and by Fabian Pascal. I
> held a dialog (that reads more like a monologue) with Pascal and it is
> reproduced in total if you scroll to the bottom of the
> http://store.tincat-group.com page and click on the Dick Pick / Ted
> Codd Blue Brothers parody picture. I had not been reading this news
> group until lately, but it strikes me that this is a group that might
> be very entertained by that dialog.....
Regarding that Acrobat page of yours, I would like to make a few
comments.
First off, I don't think relational dictates fixed sized variables.
It is true that current implementations do this, but I don't
see it a "rule of logic" that dynamically-typed, or type-free
"cells" cannot be part of a RDBMS. You may want to take a look at:
http://www.c2.com/cgi/wiki?MultiParadigmDatabase
But, your bicycle example bothered me a bit. It seems to be an
IMS-like hierarchical model where an "all the things that X owns"
sub-list is made for each person. In practice, we would probably get
"Schwinn" spelled 30 different ways (I probably even mispelled it).
Or, if the vendor changes names or merges, that information is not
automatically "propogated" to all the child nodes. Plus, we have to go
thru the parent to query about things people own. We now have to
"navigate" a path not related to our query.
Doesn't XP also dictate factoring so that an algorithm or piece of
info is in one and only place? In that case, you are not XP-compatible
there because bicycle brand names and perhaps bicycle attributes would
be *replicated* on several nodes, since multiple people own the same
models/brands. Relational would have a "productID" or "modelID" most
likely. The ID number is "dumb" such that changes in product names or
attributes are not reflected in the keys. That is why, for example,
that employee numbers make a better key than peoples names: names are
often misspelled and people get married or divorce and change their
names. Easier to fix it in one place than on multiple child nodes.
Yes, your approach might be more "agile" since it satisfies
*immediate* requirements, but shanty towns are also more "agile", but
are not practical in the longer run. In that sense, I reject pure
agile approaches. Navigational (non-relational) databases do tend to
have just such a shanty-town feel in my experience. The "paths" are
built up based on the first requirements, but become awkward for tasks
not tightly related to the first requirements.
It is a matter of being agile for the short term or agile for the
longer term.
Relational tends to describe things independent of how they are used,
and this is one of its best benefits. Sure, it does not always
perfectly satisfy that goal, but comes closer than any existing
database model.
Further, your complaints about relational rows and not being able to
get the output report format you want are apples and oranges. You need
a report generator to get various output formats. Relational queries
are not meant to replace report writers when choosey about format
(sure, it could get you a quick-and-dirty result). If we hard-wire
information management to fit one report, it will be less likely to
fit another. The same piece of info often shows up in multiple reports
in practice. Why favor just the first round of requirements at the
expense of others?
In short, I would rather improve upon relational rather than toss it
to get some of the "dynamic" features you describe. I agree that the
"Oracle model" of relational is a bit stodgy at times, but a return to
navigational databases is not a fix.
-T-
Received on Sun Oct 19 2003 - 21:37:06 CEST
