>>
>>Excellent points Walter. I would have no issues with meaningful keys such as invoice numbers. I do tend to avoid using integers but primarily because I work in Enterprise systems and have been seen this bite the budget terribly. We had to dump a very large project to separate a large enterprise system into 3 different regional systems due to the use of sequenced integers for everything. There were already billions of rows in many tables and the cost to break this up was prohibitive. The integer keys was the breaking point. I would not have an issue using integers for lookup tables or smaller systems, but who knows sometimes where it will go. I see little harm or downside in using GUIDs for my efforts, so tend to stick to that.
>
>Same here. There is a lot of mis-communication and misunderstanding in IT. Many people go by Joe Celko's stuff, but even so, he's human and things are open to interpretation. This article is a good way to determine what kind of key:
>
>http://www.informationweek.com/software/information-management/celko-on-sql-natural-artificial-and-surrogate-keys-explained/d/d-id/1059246?
>
>First off, let's note that he does not say surrogate keys are bad. Artificial keys are bad.
>
>In "ACM Transactions on Database Systems," Dr. Codd wrote that "…database users may cause the system to generate or delete a surrogate, but they have no control over its value, nor is its value ever displayed to them...
>
>This means that a surrogate ought to act like an index, hash table, bit vector or whatever; created by the user, managed by the system and NEVER seen by a user. That means never used in queries, DRI or anything else that a user does."
>
>I disagree with that last part. A surrogate key is a key. The user is not supposed to see it. The system is supposed to manage it. So if the user initiates a query, I see nothing wrong whatsoever with the system executing that query joining tables on the surrogate key, or the system managing referential integrity with that surrogate key.
>
>I would not use the invoice number as the primary key. There is a huge benefit to doing every table and key the same way. That benefit is "practice". You should not have to decide per table what kind of key. That, to me, is like a drywaller choosing between screws, glue, tape, per joint.
>
>If I have a 10 digit customer number in the customer table, and a 10 digit invoice number and a 10 digit line item number, to track payments against line items, what I have a 30 digit key on the line item? Everybody knows keys must be short! So how can anyone argue in favor of natural keys?
>
>Space is cheap, ram is cheap. This continual debating over primary keys is SOOOOO WASTEFUL to the entire planet!!!!

Yes, I would typically not make a bunch of primary keys based on different tables use different schemes. I tend to pretty much just create a Uniqueidentifier for each table to be the primary key. It helps in the issue of merging data or separating data later if the need arises. It is far too easy and removes any question. But I would not pitch a fit if someone used an invoice number that is generated and cannot change for a database I am not in charge of. I just would not likely do that myself.

While on the topic, a similar questions. Are people adding a separate Primary key to many to many join tables or using the two Foreign key fields as that purpose?