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@xxxxxxxxx] Sent: Monday, November 27, 2006 2:30 PM To: Brandon Aiken Cc: pgsql-general@xxxxxxxxxxxxxx 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@xxxxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFazzQUy30ODPkzl0RAs/sAJ9rBTbXPNN/T4eQ9zjJFMAKFpfrPACdHcLj pVtAZhjxk24vgRm/ScNfuyw= =mLTC -----END PGP SIGNATURE-----
