Re: ID field as logical address

From: Bob Badour <>
Date: Fri, 29 May 2009 14:36:05 -0300
Message-ID: <4a201cea$0$23752$>

paul c wrote:

> Just a couple of comments about a post that is unusually vague and fuzzy
> coming from you, it's tedious to dismantle every sentence, so I mention
> only a couple:
> Walter Mitty wrote:

>> ...  Now let's say you have a table that records values that look like 
>> (ID, value).  In an actual case, value would probably ityself be a 
>> tuple,  ...

> Sounds like you are talking about a tuple within a tuple, the tuple that
> 'value' stands for being somehow 'within' the tuple that '(ID, value)'
> stands for. I don't think there is a relational notion that matches
> this, maybe you actually have RVA's in mind.

Tuples as data types and data values are perfectly fine. What's wrong with them?

> ...

>> So, Brian's claim that deleting a value and inserting a new one is 
>> somehow really different from updating an existing value works in this 
>> model,  if you regard ID as somehow "special",  and not "part of the 
>> value recorded in the table".
>> ...

> He is not the only one who talks about one thing and means something
> diifferent. Here, at least one of you is dreaming of a table that
> doesn't stand for one of Codd's relations. (Apparently SQL is capable
> of the same thing, for reasons such as unnamed columns. According to
> Date another flaw was that SQL is based on 'bags', not sets so it
> wouldn't be a surprise if Codd shunned the System R department when he
> worked for IBM.)
> The first thing the mystics forget is that they can't make their claims
> without admitting that they are talking about something other than
> conventional relational theory. Their claims should be dismissed until
> they develop their own formal theory for whatever machinations they have
> in mind and make their assumptions and variations precise. Relational
> theory is still developing but people who refuse to give substitutes for
> the very few formal concepts only get in the way of progress.

Very well said.

> Meanwhile, aspects of Codd's theory have loopholes such as whether some
> views can be 'updated', constraint theory is mostly undeveloped, etc.
> The majority of posts to c.d.t. are about physical questions. Regarding
> the topic at hand, I've never seen it asked here whether there is any
> logical reason why views can't have generated attribute values If a
> view can have D&D-style extend-ed attributes, is there a use for
> generating values? One possible use might be to simplify quota queries.

Values are values. What difference does it matter how one arrives at them?

> (Depending on how you read Codd's 1970 paper, he might have left the
> door slightly ajar when he described his reduction algorithm, because
> one can imagine hierarchies where arbitrary attributes need to be
> introduced. If there are hierarchies that can't be shown as relations
> without introduced attributes, are there relations that can't be shown
> as tables without introduced attributes? I think Codd might have said
> that if there are such relations, they should be avoided, but that's
> just a guess. I'm certain he would have said such situations weren't
> the problem he was after solving. Nevertheless, Codd never precluded
> such attributes as fas as I know, eg. he didn't forbid an attribute's
> value being generated by the machine.)

Of course not. Why would he forbid anything without cause? Received on Fri May 29 2009 - 19:36:05 CEST

Original text of this message