Re: theory and practice: ying and yang
Date: Mon, 06 Jun 2005 08:25:31 -0400
Message-Id: <d3sdn2-tnl.ln1_at_pluto.downsfam.net>
mountain man wrote:
> "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.
OK, I see.
But when the external code writes a report, how does it know what the column titles should be? How wide the columns are? It must somehow consult the database to find out? It was in answering this question that we finalized our relationship between the tiers and settled the code generation question. We decided that at upgrade time the builder would supply the external client with a copy of the dictionary in the native format of the client. This then became the sole and complete touch point between the layers on the what the nature of the running system was.
Also, alas, to make a rich human interface, you have to have the ability to provide *additional* UI elements. I say additional because the table-like system you already have is in fact very important, you want to add to it, not replace it.
>
> 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.
>
At a very early stage of my current project, I considered having a data dictionary that was "pure" in the sense that it contained no information about the UI. This idea I rapidly dropped. You have to put info into the dictionary to guide the UI, such as column ordering information at very least, and simple captions.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Mon Jun 06 2005 - 14:25:31 CEST