Re: In an RDBMS, what does "Data" mean?

"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. 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, particularly a vendor-specific declarative language that is difficult to convert from one db to another.

> I think I'm starting to agree with you on this, but still don't think
that's
> the province of relational - at least not yet. I would like to see
> discussions on a standard system catalog - in essence, relational
statements
> about relvars! Since the catalog is a set of relvars like the others, yet
> describes those others, we now have true relational metadata, an
interesting
> topic...
>

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 Received on Wed May 19 2004 - 19:20:52 CDT