Re: What are the design criteria for primary keys?
Date: Sat, 4 Sep 2010 15:02:26 -0700 (PDT)
Message-ID: <eb137051-db9f-4322-a217-356449cbd0cf_at_u6g2000yqh.googlegroups.com>
I think you meant "Shark" and not the Lewis Carrol mythical beast.
With data, I do. Thank you for a wonderful "tag line" for an article or in a book!
I ask what things are really needed. Do you really need to materialize a computed column? A computation in main storage is a lot faster than disk reads. Bite it off and circle again!
Why do you have tables when a VIEW would do the job and always be current? Bite it off and circle again!
Why do you store the same data element two or more places/ways? Bite it off and circle again!
Why did you invent and maintain an encoding scheme of your own design when there is a Standard?
A few decades ago (Ghod, I am old!) I did a Nested Sets model for a company that had a "Portal Control" software package. The org chart allowed certain departments access to certain data and software (i.e. engineer can use CAD, but not Payroll) and this package enforced the rules. It went down to the employee level (Joe cannot send email because of his Hentai porno spam to the Vatican).
I got the core system down to SIX tables from SIXTY tables. We tested it on 150,000 node tree and got four orders of magnitude improvement. Okay, I am not that wonderful; the product had gone thru several hands and each time the "solution" had been to add another table. Been there, done that? :(
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint- French writer (1900 - 1944) Received on Sun Sep 05 2010 - 00:02:26 CEST