Home Forums Database Design Relational Theory Surogate Keys are not always the answer but are freqently used RE: Surogate Keys are not always the answer but are freqently used

  • David Portas (10/13/2010)


    Stability is usually a desirable property for a key and is certainly an important consideration but it isn't an absolute requirement. Sometimes it may be quite reasonable to implement keys that are unstable by design. One example is a login name attribute. The user may be allowed to change his login name at any time. The login name must remain unique though, so it's perfectly sensible to make it a key in the database.

    David, I would agree with you in one way and disagree in another. I would say the login name is stable. Yes, it *could* be altered daily. Noone would though. Now, password, on the other hand, is an 'unstable' key. In theory it should be being altered by every user every 30 days. Not quite as unstable as, say, a LastUpdate field, but still unstable.

    So, while the ability to be unstable is there, I would say a login-name would be a stable field.

    To the other part of your statement (before I get shot for symantics about 'login-name'), Unique fields can be controlled very easily with a unique, non-clustered, non-keyed index and get out of the way of the real ones.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA