Re: Specifying all biz rules in relational data

mAsterdam <mAsterdam_at_vrijdag.org> wrote in message news:<414cddcb$0$43451$e4fe514c_at_news.xs4all.nl>...
> robert wrote:
>

> >>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
>
> GL? Generation Language ?? General Level of abstraction ??

the former, but the latter as well, i guess.

>
> > 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.
> >
> > 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.
>
> Yes! ... a taxonomy (hierarchy) of types might just prove
> to restrictive, though ... but let's give it a try anyway.

ack! hierarchy??? my dictionary doesn't make that restriction: "orderly classification of plants and animals according to their presumed natural relationships".

and i'm still not clear about what is being attempted: a fully relational user system (which i find both doable and useful), or fully relational code generator (about which i am ambivalent).

if the latter, i don't have the foggiest idea how to guarantee the truth of generated code (not to mention regeneration of the code after a change of target language). Received on Sun Sep 19 2004 - 17:44:32 CEST