>Hi,
>I have read couple of articles and thread messages that suggest to use GUID or auto-generated value as primary key.
>Does it complicated while doing maintenance of error checking since we don't really know what that primary key value refer to?
My article on primary keys,
http://www.levelextreme.com/Magazine/May2002/Page14.asp, outlines the advantages and disadvantages of each approach. It seems that many developers prefer primary keys which don't have a meaning to the end-user, and also, many developers prefer the other approach. It seems, then, that there are not only advantages, but also disadvantages with the approach you are investigating.
The fact that you can't see any value that "makes sense" does, indeed, complicate debugging. But since there are also advantages, I would not discard it. Better think about it a little more.
Personally, I use primary keys that the user doesn't see. There was a time when I was convinced that this was the best way to go; now, I understand that there are both advantages and disadvantages to consider.
>Also, if I have alot of 100 tables, then I should have 100 records in my key table?
You can either do that, or use a single sequence for your 100 tables - as long as you think your system won't use more than 2,000,000,000 records in total.
I suggest keeping a separate sequence for each table. Thus, you can later use the same table for sequences which the user does see - like document numbers - for which you need separate sequences anyway.
HTH,
Hilmar.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)