Re: Specifying all biz rules in relational data

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Tue, 21 Sep 2004 22:18:51 -0400
Message-ID: <cenqic.44v.ln@mercury.downsfam.net>

--CELKO-- wrote:

>>> Then of course we have the work of Mr. Celko, that gives us a large

> set of
> solutions to known problems. The problem for those who have read the
> literature becomes learning to recognize the problem types. <<
>
> .. which is how most other trades actaully pass along knowledge; the
> apprentice carpenter/chef/musician watches the master and "steals" his
> tricks.
>
> My most recent book is on trees & hierarchies in SQL. I have several
> different ways to model them and some heuristics for picking which
> model fits your situation. I am not sure if it would be worth the
> cost to have some AI package do this for you.

I tried exactly once to generate some complex rules for picking something. It seemed to make the perfect the enemy of the good, and I've not tried it again.

Generally given x valid solutions, I will usually look for a few things:

Simplicity. Much more likely to port, much easier to maintain.
A quick run of pseudo-code and some doc checks to make sure no platform-specific tricks are being used.
Gross differences in performance.

The balance of these suggests a one-size-fits-all that the generator will then produce.

> Better to put the
> effort into a code generator that would spit out tree manipulation
> stored procedures or fill in tables from a GUI, etc.

Exactly. A bird in the hand is worth two in the bush.

Finally, if we do make even a cursory attempt to determine the best algorithm for the most situations, we've actually done more than most, and the product has a 50-50 chance of producing code that is faster than an everage programmer who doesn't bother to look up the state of the art.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me

Received on Tue Sep 21 2004 - 21:18:51 CDT