Re: Surrogate Keys: an Implementation Issue

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Mon, 24 Jul 2006 14:53:26 GMT
Message-ID: <G95xg.14287$pu3.332887@ursa-nb00s0.nbnet.nb.ca>

Paul Mansour wrote:

> Bob Badour wrote:
>

>>The physical level of discourse deals with physical locations on disk or
>>in memory etc. That's what defines it.

>
> <snip>
>

>>I suspect what people refer to as an intermediate level is the external
>>physical level of discourse as opposed to the internal physical level of
>>discourse.

>
> Bob,
>
> As you noted above, I often perhaps confuse the physical and logical
> levels. Here is something I've been wondering about. Assume one were to
> implement the relational model in a high-level intrepreted language,
> say Lisp, APL, Python, etc. These languages insulate the programmer
> from the physical level.

Not really. They simply define a new computational model for the internal implementation of the dbms.

  So it must be possible, if not practical, to
> implement the RM without ever really thinking about or getting involved
> in the physical level.

I disagree.

  So when a programmer is implementing the RM in
> one of these types of languages, what level is he thinking in or about?

If the programmer is implementing the internals of a dbms, then he is thinking about the internals.

> Is this what you mean by the "external physical level of discourse"?

No. A dbms is going to have to expose some sort of language to specify what indexes to create, how to cluster or to distribute data, when to use row stores vs. column stores etc. This language affects the physical arrangement of the data without affecting the logical design at all. Thus, it is physical.

Because the language is exposed to the DBA and can be manipulated, it is external. The DBA does not need to know how the dbms internally represents physical pointers, because the pointer representation is internal to the dbms. The DBA does not need to specify anything related to read-write heads, cylinders, etc. which are also internal to the dbms. Received on Mon Jul 24 2006 - 09:53:26 CDT