The second style you mention, is basically using a business key as the id, correct?
This is discouraged because at design time, although you may believe a key to be both unique and unchangeable, business requirements change. For example, a naive implementation might use a company's name as the id for a company. If that company merges with another, the id becomes invalid, and the system's integrity is compromised.
Using an internal id will not take up that much space, esp. if you use a generator like the 'native' generator that uses numbers instead of strings. It means that your business entities can change as required to match the evolving design.
I believe that there are a number of other posts asking this question, more information is available with a little searching.
|