Re: Normalization, Natural Keys, Surrogate Keys

> They are blowing smoke. How do I know? They are selling to a government
> agency that has far more money than knowledge.
Yes, I believe that is the case here, too. There go my tax dollars...

> few exceptions, make a practice of bad practices. That anyone is paying
> money to a vendor without knowing precisely what is being purchased is a
> nightmare that is played out every single day all over the world.
I know, I was a VAR for seven years. It was great for us. Now I'm on the other side and I am trying to stop the flood.

> That being said Oracle is probably a far better choice the than products
> that you know

Not suprising. Though I would suggest you check out MySQL. It is gaining ground on Oracle, IMO.

>You folks should bring in an OUTSIDE expert to
> evaluate their proposal. A couple of hundred thousand dollars could save
> tens of millions.

Funny you say that. They have. This company, however, is working "hand-in-hand" with the consulting company. Um, doesn't that defeat the purpose of an oversight company?

> With respect to natural kes vs surrogate keys I go with natural keys
> every time. The problem with surrogate keys, especially in an environment
> such as yours is that they allow, by their very nature, duplicate data
> entry. Unless, of course, you wish to create a second set of constraints
> and indexes to enforce what the primary key would normally enforce.
I would disagree. Unless you can explain further. I'd like to see an example of why this would be. :)

>And that Oracle
> Corp. will take the PR hit

Unfortunate, isn't it? Oh, by the way, I just yesterday that we will apparently have extra copies of Oracle design tools to spread around. Hmm, wonder why that is?

Thanks!

Kai Received on Fri May 17 2002 - 09:14:21 CDT