Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
From: Andrew McDonagh <news_at_andmc.com>
Date: Thu, 01 Jun 2006 19:52:16 +0100
Message-ID: <e5nd17$qr8$1_at_news.freedom2surf.net>
>> 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.
Date: Thu, 01 Jun 2006 19:52:16 +0100
Message-ID: <e5nd17$qr8$1_at_news.freedom2surf.net>
Bob Badour wrote:
> 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.
Agreed - UIs always take far more code to produce than database or server side applications. They tend to require more detailed thread handling too, so as to ensure responsiveness and over all user experience. Received on Thu Jun 01 2006 - 20:52:16 CEST