Re: What are the design criteria for primary keys?
Date: Fri, 03 Sep 2010 23:28:04 -0300
paul c wrote:
> On 03/09/2010 6:30 PM, -CELKO- wrote:
>>>> Celko wants everybody to use published keys, sometimes that's >>>> advantageous but it's not essential, after all the published keys >>>> one has never seen before aren't familiar before one adopts them.<< >> >> I like industry standards for several reasons: >> 1) Validation = Can I look at it and see the form is correct? >> 2) Verification = Can an external source map the key to the entity? >> 3) Universality = Does everyone agree on the meaning? This is the >> idea of a trusted source to maintain the standard for me (the >> laziness principle of programming). >> >> I think this is more important than familiarity, which is >> subjective.
> (how did I know you would reply?)
> The first two, whether one likes them or not, are probably de rigueur
> for a corporation, especially bigger ones, whether one likes that or not.
> I'd say universality is a crock. Most people don't bother normalizing
> address attributes when a postal code is involved even though strictly
> speaking one might think they should. Because they know that the postal
> services of a hundred countries will never agree on a standard, let
> alone the upwards of a million municipalities and other jurisdictions
> could never follow the same standard for street addresses. So the big
> public as well as private postal operations have a business requirement
> that they must accept multiple representations for a single postal
> address. So db designers who try to embellish a simple 'first line,
> second line, third line' set of address attributes are just playing at
> fiddlesticks. There are more important criteria.
Try living with an address that has a street #, a phase # and a suite #. I cannot count how many idiotic programmers wrote code that threw away key parts of my address when I had one like that. Received on Fri Sep 03 2010 - 21:28:04 CDT