Search Postgresql Archives

Re: IS it a good practice to use SERIAL as Primary Key?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Yes, that's the point.  They are legacy designs, and that portion of
the design is wrong.

I'll weigh in my my .02 on this subject. After much pain and agony in the real world, I have taken the stance that every table in my database must have an arbitrary, numeric primary key (generally autogenerated). I have found that this gets me into a lot of arguments with other database guys, but never seems to cause any problems for me. Conversely, I have seen innumerable problems in the real world caused by the usage of actual data as primary keys.

Perhaps I am amazingly ignorant, but I have yet to find a case where my approach causes any real problems. What does using "real" data as a primary key buy you? The only real advantages I can see are that an individual record's data will be somewhat more human-readable without joining to other tables, and that your search queries can be simpler because they don't have to join against other tables.

On the (many) occasions that I have worked on databases with "real" data as primary keys, I just saw so many problems arise. In the real world, data changes, even supposedly unchangeable data. When using arbitrary primary keys, all you have to do is change the data in the one table where it lives. If you are using real data as your keys, you have write complex queries or code to "fix" your data when the supposedly unchangeable data changes.

Anyway, I'm sure this is a huge argument, but that's my 0.2




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux