Re: the relational model of data objects *and* program objects

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote:

> On the db side it is a "code assembler". I am beginning to settle on the
> term "Automated Software Assembly" (opponents can then call it Automated
> Assembly of Software, ASS, ha ha) to distinguish it from CASE and RAD.
> Each item in the db spec requires some snippet of code, with some
> substitutions of table and column names. Those are assembled and then
> loaded into the server.
>
> On the client side we have found it easiest to have the builder copy the
> spec into the client area, and install the latest library code.
>
> I wrote the builder first in C#. Then when I switched over to Linux
> completely I translated it to Java (Mono didn't do it for me), and then I
> made the happy discovery of PHP, it is now in PHP.
>
> But I should stress strongly that it is not a PHP app, it is, for today,
> implemented in PHP. Our attitude towards all programming languages is
> "this too shall pass", the asset value is in the specs. The builder must
> be kept simple and small so that a complete reimplementation of it in The
> Next Big Thing 10 years from now would be a very small investment.

Supposing in its final state of completion a suite of application software objects were required to be contructed in such a manner that say 80% of the lines of code are to be created as stored procedures, triggers, etc and only 20% of the code for the (client side) user interface.

This methodology which you outline above and elsewhere, can it also be applied to creation of SQL stored procedure code, to the extent exemplified above.

Or are you generating 100% external dbms code?

Pete Brown
Falls Creek
Oz
www.mountainman.com.au

PS: What's the drift with the <AOL> tag </AOL>?   Received on Mon Apr 25 2005 - 13:42:43 CEST