Re: ID field as logical address

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:vdUTl.29814$PH1.1299_at_edtnps82...
> 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:

I apologize for how vague and fuzzy this topic is. If my wording is vague and fuzzy, my thinking is even more vague and fuzzy.

The first thing is whether or not I'm talking about a tuple within a tuple. This was a digression. As far as I'm concerned, the difference between the following two is not fundamental:

(714, Joe, Friday, 234-5678)
(714, (Joe, Friday,234-5678))

At least not fundamental for the purposes of figuring out how "714" comes to be associated with Joe Friday and not with some other policeman.

Next, the question arises whether the association is managed by the database or whether its managed programatically or by some external function, manual or automatic.
Some responder addressed precisely that question. I think it was Bernard. In my experience discussing this topic with fans of the ID field concept, I've found that, contrary to Bernard's opinion, they turn over management of the association to the database. I smell a rat at this point, because I think they are asking a database to perform a function that is not really a database function. I think that assigning 714 to Joe Friday is inventing data, and it's not the database system's job to invent data. It's the database system's job to manage the data it's given. That's not to say that some popular tool like MS Access might not do it anyway.

And it's not clear to me whether MS Access is really a DBMS. I think it's an application management system.

I think the process by which 714 comes to be associated with Joe Friday is actually somewhat mysterious. Googling "Badge 714" confirmed this opinion. BTW, I an NOT using "mysterious" as a code word for "mystical". The one thing I can say is that it's not a consequence of the data. It's either part of the data as given, or it's part of some fairly arbitrary process.

Next, my statement of the issue is fogged by my own ignorance of relational theory. My introduction to relational theory was only as a backdrop to my introduction to database design. At the time, I was learning how to design SQL databases, which all of us called "relational databases". I don't recall if I heard Ed Codd's name, but I know I never read anything he wrote until much later. This informal and spotty education notwithstanding, I continue to view my own interpretation of relational theory to be largely orthodox, when compared to some of the crazy things that have been accepted as "best practices" in database design.

Anyway, how would relational theory decribe the operation that I called "UPDATE" (using the SQL keyword intentionally.)? would it be something like the following?

relvar R gets assigned relvar R minus relation(tuple T) plus relation(tuple U).

How does this differ from a DELETE followed by an INSERT?

I don't think this post clears up any of the fuzziness. But maybe it lays the groundwork for clearingf it up. Received on Sat May 30 2009 - 14:19:23 CEST