Re: In an RDBMS, what does "Data" mean?
Date: Fri, 21 May 2004 13:42:12 GMT
Message-ID: <UGnrc.19597$2Z2.10700_at_newssvr31.news.prodigy.com>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c8gtl5$g6q$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:ocQqc.19366$fG.17278_at_newssvr31.news.prodigy.com...
> > "mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message
> > news:3Nrpc.40241$TT.30435_at_news-server.bigpond.net.au...
> <snip>
> > Change management is the name given to the bag that holds
> > > together everything that falls through the cracks of theory
> > > and out into the world of practice.
>
> I think we agree on the problem being a rather narrow definition of
> databases or a vertical partitioning of the software development problem
> that isn't necessarily the best.
Yes, I think so - my preference is to push things that have to work together from a single source, via a template-driven code generation approach (in lieu of higher-level languages, though code generation amounts to the same).
> Your solution to place everything "in the
> database" (if I understand you correctly) is fine from my perspective, but
> not the one I lean toward naturally -- I'd prefer an OO language to a
> declarative one,
Why not both? Something like Tutorial D, which offers both OO capabilities for domains, plus relations? In any even, we'll have to agree to disagree on the value of declarative... I'll simply point to the explosion of Java frameworks (Struts, Avalon, blah blah blah) and even language extensions (e.g. AspectJ). The "config files" are in most cases declarative statements of system structure, and in the case of aspects, are "cross-cutting" concerns which indicate the failings of the OO language (and I'd argue the OO paradigm itself). Languages like Lisp and Haskell don't require such "cross-cutting" because the languages themselves support abstractions orthogonal to objects. More than OO is needed, I think.
> particularly a vendor-specific declarative language that is
> difficult to convert from one db to another.
Couldn't agree more - a vendor-specific language is worthless. Witness even the various proprietary "extensions" to SQL...
> Agreed that the system catalog would be a good place to make some industry
> gains. For metadata such as "keywords" I'd think that employing those
> nested relations might give SQL-DBMS's or RDBMS's a place to start getting
> their operators shaped up for relation-valued attributes (or whatever one
> wants to call them) -- just a thought. --dawn
Interesting - certainly relation-valued attributes would require decent relational operations. Or at least one would think. Industry might always, in its infinite wisdom, decide it knows better.
- erk