Re: front-end vs back-end
Date: Thu, 1 Dec 1994 15:56:44 GMT
Message-ID: <D052yL.1wC_at_lanier.com>
In article <rwh4+.141.00106422_at_pitt.edu>,
Richard W. Harris <rwh4+_at_pitt.edu> wrote:
>In article <3avt24$6bo_at_panix.com> janest_at_panix.com (John Anest) writes:
>> We're wondering if we're the only ones writing a complex financial
>>system entirely on the back-end using stored procedures. We have thousands
>>of lines of code. We cannot keep our transactions short because they're
>>long!
>> Is everybody using the client to process the data? Are you only using
>>the database as a data repository? Is this the reality of the situation?
>>--
>
>Actually, I've heard of many organizations using stored procedures to process
>the data in an application.
>
We are relatively unexperienced in client/server development, but I have long thought that the basic functionality of an application should be encapsulated as much as possible. For Oracle, this would mean putting most of the application logic in the database design, i.e., constraints, triggers, and procedures. The client would then be a presentation with menu selections, buttons, or whatever to allow a user to invoke the centrally defined operations on the data. Obviously, complex reporting and ad hoc queries could still be in the client; I am talking about encapsulating the operations that define the basic character of the application data.
We are about to prototype a high-visibility application (Customer db) using this approach. I would like to hear from some people who have done this. Is it a good development approach? Does it overwork the server (whatever that means -- depends on the server, of course :-) ? Any comments appreciated. BTW, our development platform will be Forms 4.0 using X, with deployment possibly Forms 4.0 in Windows.
Thanks.
Donald E. Vick (dvick_at_lanier.com, dvick_at_crl.com) Voice: (404) 493-2194 Fax: (404) 493-2399 Received on Thu Dec 01 1994 - 16:56:44 CET