rob@xxxxxxxxx wrote:
Granted I am a little floored by that constraint. Let's set aside for a moment and drop down to the old method of defining a primary key constraint. The last time trial. As you can see, you INCREASE overhead by not having a primary key. So, again, what business reason is there for not having a primary key on the item master? Even if you counter argue that the data needs more time trials because of one skew I think it's fair to say that there is no overhead, performance wise.
And this really proves my point. I'm not against any particular technique; I think the decision has to be made with good information (exactly what Elvis said, I think). In this case, the constraint was a bad decision performance wise. The UNIQUE keyword was a good one. The point is that each decision needs some careful thought and possibly some benchmarks

I suspect that based on this, you might want to revisit the idea of constraints on primary keys, eh? Being as this is a one-time thing, it's my contention that you need to make each decision based on real world information, not a one-size fits all philosophy.

Joe

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].