Re: Surrogate Key Semantics
Date: Sun, 20 Nov 2005 07:44:12 -0000
This gives a better definition:
Where the RDBMS does not automatically generate one for you, not many do, you need to use your own surrogate generator like a sequence or guid.
The biggest draw back with using the natural key everywhere as a foreign key is when the primary 'natural' key changes, its also difficult for applications to use composite keys, consider a html listbox for instance.
Talk about the wrong mental model....I think you really ought to get back to basics yourself and understand just how this stuff is being used out in the real world and stop being such a dam theorist.
-- Tony Rogerson SQL Server MVP http://sqlserverfaq.com - free video tutorials "-CELKO-" <jcelko212_at_earthlink.net> wrote in message news:1131816625.610272.96100_at_f14g2000cwb.googlegroups.com...Received on Sun Nov 20 2005 - 08:44:12 CET
> Let's get back to the basics of an RDBMS. Your questions are all based
> on the wrong mental model.
> Read some of Dr. Codd's stuff on this. BY DEFINITION, you cannot name
> a surrogate key because it is hidden from you. Rows are not records;
> fields are not columns; tables are not files.
> RDBMS uses the terms "referenced" and "referencing" tables. And it
> does not say HOW that referencing is done. So anything like what you
> call a surrogate will depend on the implementation, not on RDBMS.