Re: What predicates the following relation represents

"Laconic2" <laconic2_at_comcast.net> wrote in message news:<QIudnQHKP8dMDQbdRVn-jw_at_comcast.com>...
> "robert" <gnuoytr_at_rcn.com> wrote in message
> news:da3c2186.0405070417.323ba2b8_at_posting.google.com...
> > > I gather now that you are talking about whether the language(s)
> associated
> > > with database-centric software applications should be declarative,
> > > procedural, OO, etc, right? Isn't the "comprehension of the data" in an
> > > RDBMS "encapsulated inside some inaccessible object" from the
> perspective of
> > > somone who doesn't know the declarative language?
> >
> > oh please, stop it. sql has been codified since 1986. updated along the
> > way, of course.
>
> Yes, but...
>
> There are other issues:
>
> First, the metadata isn't the declarative language. It's the record of the
> effects of the DDL (if I'm understanding "declarative language" correctly.)
> So a person might understand CREATE TABLE and CREATE INDEX but not be able
> to make use of the data.

how not? the system table is implementation specific. data access is through sql, which is codified. no one (reputable) says it's 100% of RM. indexes are an access aid, not definitional.

>
> Second, the metadata has not been standardized until around 1992 (can you
> help here, Joe Celko?), and none of the databases I've seen in the "real
> world" conform to that standard. You have to know the system tables that
> are particular to the product, and parhaps to the version of the product.

no. all you need is the names of the data objects: tables and columns. it helps to know the keys defined, in order to avoid access errors. all the rest is at the vendor's discretion. you need an engine, and possibly, a client (type 4 jdbc access doesn't for instance). i'd wager that one needs *less* implementation specifc information to query an arbitrary (non-trivial) sql database than the equivalent stored in say, xml. not that an intelligent person would use xml for *storage*, but that's another show.

>
> Third, there are items that are critical to the interpretation of the data
> that just aren't in the metadata,

what, pray tell? the very definition of 3NF (or better) contradicts this statement.

except perhaps in the form of comments.
> In particular, if you take tables to be a representation of relations (skip
> the Torquemada response, please) the proposition asserted by each table is
> not specifically represented in the metadata. Without that, you can't
> really tell what the data means.

the alternatives are no better. if the column is 'length' what are the units? utterly and completely irrelevant to why the RM is a better model than the alternatives. it's the guarantee of correctness independent of application code. ultimately, the truth will out.

that the RM removes redundant data was, at one time, viewed as an economic benefit: fewer bytes on disc. that was always a red herring, used i suppose, to convince the suits: "look only 2 3315s, not 4". the benefit is the logic.

>
> Having said all that, I think that Dawn is slowly arriving at the big
> reason why "the relational model" has not been the "silver bullet":
> ignorance.
Received on Sat May 08 2004 - 05:03:45 CEST