Re: theory and practice: ying and yang

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:krbbn2-l65.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>>
>> If the application layer can be bound within the DB,
>> and the DB now services this role, there will *not* be
>> the need for any further layers.
>>
>
> Do you mean putting HTML generation in there?
> Or storing compiled binaries for desktop apps?

Let's talk simple reporting, rather than update routines] to start off with. In the DB we have the data and we have the reports in the form of stored procedures. (NB: These reports can be multi-dimensional [summary, detail, etc] because stored proces can be chained together).

External to the database we have a tool, that has code of course, but no code related to the organisation specifically. It is code to provide services to present data sets (ie: reports) that have been generated by the sprocs on the data, and to allow the user to sort, filter and export these data sets. The same tool is used for any and every industry.

So what I mean is that these is no code which is specific to that organisation's database application that is external to the DB, it has been 100% contained within the DB, by the above method and arrangment.

You made a point at some earlier time which I did not then respond to, about the flavorless appearance of this tool, in that _all_ it appears as is a grid to hold data, and the natural desire of business owners to have pretty pictures, and specialised interface "forms" --- in the long run.

This is a valid point, and we have plans to address this issue at some stage, in order to meets such "cosmetic" needs, by means of holding such parameters within the database.

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software