In Praise of Rules of Thumb

(It's Friday ;)).

"Rules of Thumb are ROT" - Tom Kyte says this at least once a week and I've see it recently here.

I'd take a very different stance: Rules of Thumb are essential.

For example, if you come across a large, furry animal, with big teeth, that roars - you have two options:
1) by Rule of Thumb - run away.
2) by the scentific analytical method - take a DNA sample to determine the nature of the animal and hence any further action.
The survival of the human race depended on using the ROT.

Every day we are faced with decisions that must be taken either (a) with imperfect information or (b) with a great expenditure of time/money required to obtain all the necessary information. It's Rules of Thumb (the distillation of experience) that guide our decisions in the real-life case of (a).

I've frequently been asked whether WHERE EXISTS .. or WHERE .. IN .. should be used. I can't imagine anyone would spend hours to examine the database in detail to predict which would be more efficient; the only reasonable way to find out which is better, is to try them both (yes, yes, I know there are some simple cases where the choice is obvious). So, which do you try first? The Rule of Thumb says WHERE EXISTS - because in most cases it will give satisfactory results and WHERE IN won't do any better. Sometimes it is ROT and you will have to recode.

So let's hear it for Rules of Thumb - and be prepared to be wrong sometimes (but not very often).

If find that when dealing with developers, using the middle finger proves better results :p

I think TKyte's problem with ROTs is that conventional ROTs are plain wrong and are typcially applied in situations where they should not be applied. Typically with a ROT, you have some rule that says if X is Y then do Z. The conditions in which X happens need to be examined and determine if the condition is really X or is "sort of X, but closer to W".

I don't think anyone can dispute the "Common Sense" approach. Given enough experience in a particular environment, you should be able to quickly diagnose what the problem "most likely" is. However, you also have to know what the parameters for your particular situation are and when the parameters don't meet your particular situation. For example, in my environment I know when a programmer asks me to increase the "open_cursors" parameter, he/she has forgot to close a cursor somewhere probably in a loop. In your environment it may be different, and in my environment I may run into a situtation where this is not the case someday, but 95% of the time I know the solution already.

We humans live life by the common sense approach every day without knowing the exact details. I read an article recently that applied this approach the decision whether to pass another car on the highway. If we were to take the scientific approach, you would calculate your velocity, measure the distance you have to pass, apply an equation to situation, and generate a probability that if velocity and distance vary more than one distribution you will make it. The common sense approach would be to eyeball the speed you are traveling and distance and experience would tell you there's probably enough room to pass.

I got a turbo, I'll pass you and your boxster anyday!!

Can we talk about sports and politics now? This Oracle crap is boooooring!!!


:D

MH

Quote:

---

Originally posted by Mr.Hanky
This Oracle crap is boooooring!!!

---

My hidden agenda was to discuss ways of getting lions to deal with the developer problem, but no one took the bait :cool:

Quote:

---

Originally posted by Mr.Hanky
I got a turbo, I'll pass you and your boxster anyday!!

---

In my experience, Boxter trumps Ford Festiva Turbo EVERY day.

Quote:

---

Originally posted by marist89
In my experience, Boxter trumps Ford Festiva Turbo EVERY day.

---

Ageed.

;)

MH