Some database discussions...

When discussing database with a more 'traditional' developer I get
enlightened about some of the concepts we just take for granted. I
realize that some things which are obvious to us may not be for others. I
can still recall not being able to grasp the concept of a member in an
oral discussion when someone tried to explain it to me when I was coming
from my S/36 background. So I don't mean any of these as a slam but just
something to put their train of thought into perspective.

Sure there's the usual: database=system, schema=library, table=physical
file kind of stuff. But then there's some of the newer stuff.
Here's one from yesterday. We had a discussion about referential
constraints. I had to really think about the other person's perspective
when he was stuck on trying to put a column in the parent table to
associate back to the child. Picture this, Parent file with a identity
column as a primary key. Child file with it's own identity column as a
primary key. Child file has another column which is a foreign key to the
parent table and this column may not be named the same as the primary key
in the parent table. So, his thought was how did the parent know to chain
out to the child on which column to ensure that there was no match and
therefore it would be safe to remove this parent row? I had to explain
that this was all controlled in the background by DB2. It may help to
open up some of the graphical tools which will show the constraints in a
schema. Or to query the various SYS*CST* tables in the system catalog.

It was similar to a discussion during a presentation I gave on temporal
tables. How a temporal query knew to go against both the current, and the
history table, without having to use a join. Some discussion of the
system catalog was included.


Rob Berendt