Re: ID field as logical address
Date: Fri, 29 May 2009 14:36:05 -0300
Message-ID: <4a201cea$0$23752$9a566e8b_at_news.aliant.net>
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