Re: Design approaches about primary key

Daniel Morgan wrote:
>
> Van Messner wrote:
>
> >
> > A matter of design and method I suppose. You don't like public synonyms, I
> > don't like to change primary keys.
>
> I don't like either. A primary key that needs to be changed is an
> admission of a bad design.

Did I miss something here?

I'm not quite sure what part of 'invariant unique identifier' matches up to 'changeable primary key'. I was taught (about 15 years ago) that a primary key can NEVER change. Any 'unique identifier' that could change but would be relatively stable **might** be considered for use as a secondary key. Tried breaking the rule designing & building a complex system, ended up paying big-time in maintenance and various other limitations.

Not that maintenance cost is a worry to modern management, just initial implementation cost. OpEx is a different budget line and it's in the future - the accountants and economists don't worry about that! You just outsource or lay off maintenance people to manage OpEx.

Then again, I'm old school. The new kids on the block seem to have better ideas. Which seems to mean, they are doomed to repeat my mistakes.

(In other words, I concur!) Received on Fri Nov 28 2003 - 17:08:58 CST