>Part of the problem with doing something like that is that your primary key is >going to get really big, really quickly. Plus in some systems (generally >accounting) you can't have "missing" primary id's. If you do you know there is >some sort of issue.

Well, the primary key isn't going to get to big too quickly. If that was so, then it would be possible to get too big too quickly as is. It's only a constant increment. Let's say on average my tables generates 100,000 id's. If I had 400 tables, then it's only going to be 100,000 x 400. It's a constant I'm multiplying by, not anything exponential. Plus if I switched to base 64, I'd be set even longer.

"Missing" primary id's aren't a factor either for accounting, since missing id's can occur in individual tables as-is anyway. Remember, Mere Mortal's NewID() simply increments by one, no matter how many you deleted since then. Unique ID's shouldn't be used for anything else anyways. For accounting, a seperate field called iInvoiceNumber should be used if logic must be added to keep track of all Invoices. (Plus then you can use any numbering/lettering scheme a company may need) (i.e. Partnumbers, invoice numbers, customer number)



>Why not just include a foreign key in the table that needs the address that >points to the correct entry in the address table?

Because I could have more than one address.