Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 01 Jun 2006 14:43:44 GMT
Message-ID: <A2Dfg.16019$A26.371358_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> In my world there are two distinct types of application programming:
> user interface application programming, and database application
> programming. It makes sense to embed SQL in the database code for the
> reasons you give, but not in the UI code. The UI is the most likely
> bit to change in the near future, as we respond to the prevailing
> tastes of the user community ("we want it
> GUI-based/browser-based/mobile-based/...") The database part OTOH may
> not need to change for a long time, provided it performs well and
> serves the UI well. The interface between the UI and the database is
> at the level of business functions (e.g. "create an order", "produce
> bills for this month", etc.) and is typically an API.
>
> One could argue that to the UI programmer, the database is a "bit
> bucket" (very ugly term) of which he/she needs to know little.
> However, the UI is probably only 10-20% of the code, with 80-90% being
> the database application code - and to write this well you need to know
> your DBMS.
Date: Thu, 01 Jun 2006 14:43:44 GMT
Message-ID: <A2Dfg.16019$A26.371358_at_ursa-nb00s0.nbnet.nb.ca>
Tony Andrews wrote:
> frebe73_at_gmail.com wrote:
>
>>>Fair enough. But in that case you have at least committed to using a >>>SQL DBMS, and that it will be from one of the major players in the >>>market. That is somewhat different from RCM's position, which is (as I >>>understand it) that it should be trivial to unplug your SQL DBMS and >>>replace it by something else that doesn't even use SQL. >> >>The big questing is: Why do you want to unplug the SQL DBMS? It is very >>likely that the application programming language will be replace long >>before SQL is replaced. In that case, all work to decouple the the >>application from the DBMS is wasted. The productivity using an embedded >>approach (LAMP for example) is much higher than an layered/decoupled >>approach. If you make the decision to take this extra cost you need to >>be pretty sure that your application programming language will survive >>longer than SQL.
>
>
> In my world there are two distinct types of application programming:
> user interface application programming, and database application
> programming. It makes sense to embed SQL in the database code for the
> reasons you give, but not in the UI code. The UI is the most likely
> bit to change in the near future, as we respond to the prevailing
> tastes of the user community ("we want it
> GUI-based/browser-based/mobile-based/...") The database part OTOH may
> not need to change for a long time, provided it performs well and
> serves the UI well. The interface between the UI and the database is
> at the level of business functions (e.g. "create an order", "produce
> bills for this month", etc.) and is typically an API.
>
> One could argue that to the UI programmer, the database is a "bit
> bucket" (very ugly term) of which he/she needs to know little.
> However, the UI is probably only 10-20% of the code, with 80-90% being
> the database application code - and to write this well you need to know
> your DBMS.
Actually, you have that backward. In my experience, the combination of exception-handling and user-interface code account for well over 90% of the code in a typical 3gl/4gl application. Received on Thu Jun 01 2006 - 16:43:44 CEST