> -----Original Message----- > From: pgsql-general-owner@xxxxxxxxxxxxxx > [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of > Richard Broersma Jr > Sent: Monday, November 26, 2007 10:28 AM > To: Joshua D. Drake > Cc: pgsql-general@xxxxxxxxxxxxxx > Subject: Re: Primary Key > > --- On Mon, 11/26/07, Joshua D. Drake <jd@xxxxxxxxxxxxxxxxx> wrote: > > > In "theory" the item that would be a natural key in this > instance is > > the VIN. You would of course have to make some kind of > allowance for > > cars that don't have a VIN (nothing in the last what... > > 50 years?). > > So this is why the service stations always record my cars VIN > number when I show up for oil changes. ;) Ofcourse, there is > a whole industry built around auto theft where they restamp > the stolen car with a differnt vin number. I wonder if these > stolen cars end up with duplicated VIN numbers or if the > VIN's they are given do not pass the the VIN check-sum (if > such a think exists). > > Regards, > Richard Broersma Jr. > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx > so that your > message can get through to the mailing list cleanly > VIN encoding is covered here http://en.wikipedia.org/wiki/Vehicle_Identification_Number Looks like a poor choice for a primary key: too many confliciting, "meaningful", evolving-over-time digits that can be mis-interepreted by your customers. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
