Re: Specifying all biz rules in relational data

Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:<nds2ic.qqr.ln_at_mercury.downsfam.net>...
> My own first principle is this: Code is a non-portable depreciating asset,
> while data is a portable appreciating asset.

I agree wholeheartedly. My own principle is also very similar to yours: things that can be data need not become code.

Code portability or language longevity is usually not an issue for me though. There are many languages these days that are portable to every device you can think of. And with the increasing trend towards virtual machines, portability will become even a non-issue. As for longevity, most projects are shorter than the lifetime of a language. We can expect Java to still be around 30-50 years from now. Look at COBOL and FORTRAN, when are those two going to die? :-) And of course there's LISP and Smalltalk which probably will live on forever.

What's most attractive in storing information (and that includes algorithms or business rules, as they too are information) as data structure is that manipulating (changing, updating, etc) data structures is so much easier and well-defined than modifying code. Even if you're using LISP.

Unfortunately, code generation often leads to time-wasting, ideal-chasing, non-productive activities. For me, that is. :-)

--
Pascal Damian