Zein, what you're suggesting is called a natural key, composed of meaningful business data. What Dave suggested is a surrogate key, made up out of thin air, often a GUID or an incrementing integer. There are pros and cons to both. Google for natural surrogate key and find some discussions about which ones work well in what conditions.
My corporate environment dictates surrogate keys in almost all situations. Right now I'm considering playing with natural keys in a small database just to see how it works out.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Mar 31, 2005
Hi Stan, Thank you for your response. I have read about what you mentioned in your post. I get the feeling that surrogate keys are favoured over natural keys.
In my personal case, I think a natural key is the best, but i get the feeling surrogate keys are favoured mainly because overtime business logic changes, or migration may occur in which case natural keys can become particularly messy.
I do however lack corporate experience, so may there's something seasoned developers have experienced that I'm yet t learn?