Re: Specifying all biz rules in relational data
Date: Tue, 21 Sep 2004 22:18:51 -0400
Message-ID: <cenqic.44v.ln_at_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 meReceived on Wed Sep 22 2004 - 04:18:51 CEST