Guidelines to a decent support of surrogate key implementation

From: Cimode <cimode_at_hotmail.com>
Date: 24 May 2007 00:58:51 -0700
Message-ID: <1179993531.222375.136310_at_o5g2000hsb.googlegroups.com>



Lately, I have brought emphasis on the subject of concatenated keys vs addition of column. I have noticed then that the thread quickly turned to a debate about the failure of current dbms's to bring a decent support of surrogate key implementation. From what I observe 3 line of thoughts trends appear:

LINE1> People who think that surrogate key should be an internal physical mechanism to the dbms and invisible to designer who could focus on the logical selection of primary keys LINE2> People who think that a trdbms should allow the designer to have some control
LINE3> People who think there is nothing wrong with current surrogate key implementations

I personally belong to first category.

What do you think are the Pro/Cons of each approach? Here is mine:

LINE1>

	PRO
		Designer can focus better on logical design.  Less error prone in
key implementation
		Independence between the logical and physical layer is implemented
at design time.
	CON
		Surrogate key implementation becoming internal addressing pointers,
users can not find any more familiarity in surrogate keys. Assuming familiarity is an advantage, that would become a CON.

LINE2>

	PRO
		Familiarity
	CONS
		Introducing a part of subjectivity in key generation process

LINE3>
	PRO
		?
	CONS
		Keys implemented are not primary key implementations
		Product oriented bias for definition of keys
		All consequences arising for not having identity


Thank you for bringing your insights onto this theme. Thank you for respecting the frame/structure for conciseness's sake.

Regards all... Received on Thu May 24 2007 - 09:58:51 CEST

Original text of this message