Re: Specifying all biz rules in relational data

robert wrote:

> Kenneth Downs wrote:
>

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

Ah! Fresh tones in this jam :-)

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

Part of which may be graphical.

>>In my case the DD is itself a set of normalized 
>>(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.

I do not consider myself a fanatic (oh well, which fanatic does, so that doesn't say very much). More convincing?: Nobody ever accused me of fanaticism (yet).

I like prolog. I toyed with it in the '70s and early 80's. I wish it would me more widespread because it is really good at what it's good at: match-searching (backtracking, depth-first) complex problem-space trees.

What you can express in prolog, you can express very intuitively. Check swi-prolog (or another one) - play with it. It still carries a lot of things to learn for most.

Dead? That would be a pity with the current state of knowledge. But I'm optimistic. I dont't think it is dead. Check the usenet group.

Yes this French/Scottish idea is the champion of the declarative programming approach,
no, self modification doesn't bring the magic romantics hoped for. Neither does the approach of hand-tuplifying (databasing) code.

But I do agree whith you on the sound of the OP. That's where he is heading.

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

Here we do not agree. The project just take a little (<== yep, cynical understatement) more time than some of us thought.

A good friend of mine was heavily involved in a dream-explanation therapy expert using prolog in the early 80's. I used to challenge him to device an artificial jamming musician. He agreed with me that the AI community should be able to do that before entering the realm of dreams - but I'm digressing :-)

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

GL? Generation Language ?? General Level of abstraction ??

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

Yep. Some of the loss will be deliberate in any such aggregating effort, though.

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

Yet, change does happen. Early COBOL by
assembly programmers who had to make the switch wasn't nice, but they learned,
eventually.

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

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

Yes! ... a taxonomy (hierarchy) of types might just prove to restrictive, though ... but let's give it a try anyway.

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