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

mountain man wrote:

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

We would not state it that way, because our design assumptions are different, but let me do what I can to answer the question.

First, when we say "final state of completion" for an application, we don't mean any code or deployment, but rather a specification, something like:

table order_details {
 foreign_key { table_id_par: orders; }
 foreign_key { table_id_par: items; }
 column { qty; }
 column price { automation_id: FETCH;
  auto_formula: items.price; }
 ...
}

Next we apply the term "final state of completion" to a server platform such as PostgreSQL or MS SQL Server. The final state of completion is when a builder has been written that can take the spec above and create server objects that completely implement the business rules.

Then the "final state of completion" for a client is that it knows how to read and cache the DD and drives all of its operations from that, and cannot be broken by changes in the structure of the database.

Finally we look at the 80%/20% ratio you provide. Our design goal is to have the server implement 100% of business rules. So we don't speak of a ratio of code (80/20 or 50/50) but rather where a feature is implemented. The design goal here at SDS is to have the server implement 100% of features, we do not speak of the middle tier as the "business layer". So perhaps in that respect 100% of the code would be in the server, and the next 75% in the web layer, and the final 50% in the browser :)

The driving motivation behind all of this is that the biggest asset you can have is that specification a few paragraphs up, that is the real fruit of human ingenuity. Implementing it on any given platform ought to be automated.

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

The "builder" as we call it generates 100% INTERNAL dbms code. We happen to do triggers, not sprocs, but yeah, it is all on the server.

The builder also copies the spec into the web server's directory, in a format the client can use (for PHP, this is associative arrays). The web server layer uses this to build forms, save some unnecessary trips to the server for grossly misformatted data, and so forth.

>
> PS: What's the drift with the <AOL> tag </AOL>?

Well its normally considered silly to reply to a big post with simply "I agree" or "me too!". But sometimes a post is good enough that you really want to do that (which I did). It so happens AOL chat boards are rife with (or used to be) lots of "me too!" messages. So doing the AOL things says "I know I'm not adding anything at all to this, but I really liked your post". Next time I think I'll just say, "I really liked your post".

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)