Re: Surrogate Keys: an Implementation Issue

"Paul Mansour" <paul_at_carlislegroup.com> wrote in message news:1153486989.391427.38540_at_m79g2000cwm.googlegroups.com...
>
> paul c wrote:
> > I feel like my mouth has been taped over, hands cuffed and head tied to
> > a bouncing ball and my neck is aching from trying to follow it.
> <snip>
> > "produce the result" is a tricky phrase because it hints at both logical
> > and physical. We must separate how we produce from what results.
> >
>
> paul c,
>
> Sorry if I've given you a headache, and thanks for your patience!
>
> I may be mixing logical and physical models in the discussion. I think
> part of the problem is that there may well be a third,intemediate level
> that I'm really attempting to discuss. Sort of like the TRM -- it's a
> layer bewtween the logical and physical.
>
> In the below discussion, I'll use "table" and "row" for this
> intermediate level, and resort to "relation" and "tuple" when refering
> to the logical model. Considers the following "table":

PMFJI. The substance of this discussion is generally more abstract than I'm comfortable with. I don't intend to distract.

I think you are right about the third level, and I think your choice of "table" and "row" is useful nomenclature for that level.

I'd like to suggest a name for that level, namely "Database Language". SQL is a database language, and possibly the most widely used, and it uses the nomenclature "table", "row", and "column". Since 1992, it's also used the term "domain", although some SQL diealects used it in 1986 or earlier. That's NOT to suggest that every discussion about tables rows and columns is necessarily guided by the syntax and semantics of SQL. However, avoiding mentioning it is like not talking about the elephant in the room.

I'd also like to suggest that the "logical vs physical" distinction has evolved over the last 30 years, and in particular over the last six years, while I've been reading this newsgroup.

My first exposure to these terms in a database context was, IIRC, in an early book by James Martin. IIRC, that book didn't even discuss relational databases, or, if it did, I skipped over that part. In any event, the "logical vs physical" distinction there resembled the distinction that in OO parlance is referred to as "public features vs private features". That is, if the programmer (really the programmer's program) can see it, then its logical, but if not, then it's physical.

Current parlance in this newsgroup, if I understand it right, seems to focus on a different logical vs physical distinction. It's something like "conceptual" vs "implementation", but I can't quite pin it down. And I don't think the newsgroup's glossary pins it down either.

The difference between these two meanings is subtle, but important.

And, just to offer an opinion, many of the people who use a "relational DBMS" use it in an environment where the application code is decidedly NOT relational. It's either "classical procedural" or "object oriented", but it's not relational.

That's not to say that queries can't do a whole lot of relational ops on the data before delivering it to the application code, but it is to say that the data model inside the app is just not a rational implementation of a relational logical model.

I think that's areason for many of the discussion disconnects we see in here. If threads are crossposted to an boject oriented newsgroup, the disconnects get even more intense. Received on Sat Jul 22 2006 - 15:15:13 CEST