Re: Specifying all biz rules in relational data

Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:<n8pshc.lvb.ln_at_mercury.downsfam.net>...
> My own experience and inclination has always propelled me towards code
> generators and database generators, leading to my current project, which is
> a complete application generator.

well, code generators (specifically so named) began with COBOL in the 1970's. since expired. the 80's and 90's gave us 4-GLs. also expired. XML is au courant. will also probably expire. of course, VB continues to promise programming without coding. YMMV.

>
> One of the philosophical cornerstones of all such projects is that the
> application can be specified entirely in some defined format.

which ends of being a language the users (nee: coders) must learn.

 In my case
> the DD is itself a set of normalized tables (though for reasons not
> discussed here its persistent storage is not necessarily in a DB Server
> product).
>
> I wonder what the participants in this newsgroup feel about that
> proposition, that being that a database application can have its entire
> behavior defined by scalar values that can themselves be organized into
> relational tables.

was attempted about the same time codd invented the RM. it's called Prolog. has ended up a dead end (branch?) in the family tree of languages. a few fanatics like it. it is declarative. and it is a self modifying execution engine. neither is necessarily good. but it does sound like where you're headed.

>
> The practical use of the idea is simple. Out of the DD, via the generator,
> are the three things that must be synchronized:
>
> -> The docs
> -> The app code (for me, that's pure UI, no biz rules)
> -> The db (all tables, constraints, triggers, views, etc.)
>
> There are other tricks too, most notably that an upgrade is the same thing
> as a fresh install. The generator is actually a differences engine,
> comparing existing DB structures to specifications, and
> adding/changing/dropping as needed. This means there is no separate code
> for an upgrade versus a new install.

given that no one (so far as i know), has yet been able to devise a universal cross language translator or even compiler (modulo C), it sounds like more effort than it's worth.

>
> The universal objection to such systems seems to be that they are crippled
> by whatever the author has chosen to support in the DD/generator.
> Underlying this objection is Godel's False Bastard Theorem of Software
> Development: "Given any set of tools for using relational data, there
> exists a situation that can be modeled with relational data but cannot be
> implemented with those tools." In the realm of data modeling, it seems
> that we can break that assumption with brute force.

don't quite know what Godel or Bastards have to do with it, but raising the GL necessarily hides (aggregates in specified ways) lower level capabilities. there are known issues both with the RM and real world implementations: projection-join anomaly and updateable views, to name just two. so, the RM can't model everything, and even if it could, a tool which aggregates its semantics loses some part of that semantics.

in a later part of this thread is the notion that the "language of the month" could be swapped out (COBOL for Lisp, let's say) at the whim of, well, the owner of this Magic Bullet. who would know whether the generated system was still correct? how would anyone know, save by exhaustive enumeration of every path through the code? not to mention that the folks who have to use the Magic Bullet generated code become instantly redundant; replaced by experts in the "language of the month". i suppose that coders are as expendable as cogs in a machine, but the Magic Bullet Co. might find their ability to staff inhibited by this.  

> 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.

you've taken a course in differential equations? there are a known set of solution methods (no, i don't remember them; way too many years ago). a solvable equation (not all expressible are solvable) is generally amenable to only one solution method.

 Is it going too
> far to say that if we could learn to recognize the problem types,

let's start by acting like lowly biologists: define the types. you need the taxonomy first.

 then we
> could reliably model anything by either:
>
> -> Recognizing a simple problem as a recognized type, or
> -> Casting an apparently "unique" problem into a form that is recognized.
>
> In other words, the claim is that there are no unknown problems, only
> unrecognized forms. If this is true, then it follows that a finite set of
> tools in a DD/generator could generate a solution for any problem that can
> be modeled in relational data.
>
> Just curious as to what people think.

BobTheDataBaseBoy Received on Sun Sep 19 2004 - 01:45:10 CEST