Re: candidate keys in abstract parent relations

Observation:

Nobody here proposed looking at Industry Standards. Why do we like to re-invent the wheel? I know that Tony hates to research, follow Standards and all that other stuff that get in the way of a "agile/ extreme/ cowboy coder" image -- and job security :). But why did Roy miss the entire music industry? This is the guy who knows about additive congruential methods of generating values in pseudo-random order!

I offer that we are still thinking like "procedural coders" and NOT like "database people" instead. We re-invent the wheel because it is fun. It is also faster than research -- Hey, why look for a relational key with all its validation and verification rules, documentation, updating, etc. when you can use IDENTITY mindlessly and effortlessly to mimick a pointer-based DBMS or "roll your own" encodings !

I did a 30 minute consulting job two Christmasses for a mail order BBQ company. The problem involved packing boxes. Everyone else who posted to the question was trying to write a "3D Tetris" program. I realized that they had over 4 years of shipping data with Fed Ex. Do a relational division on the shipments. Find the minimal box size/dry ice combo used for each shipment. Put that experience in a look-up table with about 8000 rows. Hnadle the 0.2% stuff not in the table as an exception. Go home in 30 minutes or less. Oh, the query runs 10,000 times faster than the "Tetris" proposals.

Comments? Received on Fri Jan 20 2006 - 06:37:16 CET