It's an arbitrary identifier that only has meaning within the context of
the database. The domain model isn't supposed to model data in a
database. It's supposed to model data which coincidentally is going to
be stored in a database.
As far as your bank's poor software design, I can't help you there.
That's simply poor planning.
Look, I'm not denying the benefits of surrogate keys. There are many
cases where it makes the most sense to use them. My only point is that
it *does* violate the relational model. The fact is that's nothing
special or new for a DBA. The SQL standard itself violates the
relational model by allowing you to create tables without primary keys.
--
Brandon Aiken
CS/IT Systems Engineer
-----Original Message-----
From: David Morton [mailto:mortonda@dgrmm.net]
Sent: Monday, November 27, 2006 2:30 PM
To: Brandon Aiken
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] IS it a good practice to use SERIAL as Primary
Key?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Nov 27, 2006, at 1:21 PM, Brandon Aiken wrote:
> The other argument is that it's redundant data with no real meaning to
> the domain, meaning using surrogate keys technically violates low-
> order
> normal forms.
It has real meaning in the sense that it is an internal identifier
that doesn't change. My bank set my online login to a stupid 5
letters of my name plus last four digits of SSN, and they "can not
change" it. Most likely, it is the primary key used for as a
foreign key to all the financial data. Dumb, dumb, dumb.
If, OTOH, they would go with an internal id, it would be trivial to
change the login id.
David Morton
Maia Mailguard http://www.maiamailguard.com
mortonda@dgrmm.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFazzQUy30ODPkzl0RAs/sAJ9rBTbXPNN/T4eQ9zjJFMAKFpfrPACdHcLj
pVtAZhjxk24vgRm/ScNfuyw=
=mLTC
-----END PGP SIGNATURE-----
