Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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.

This is a lot different from RCM's stance (as I understand it), which is that even the developer writing the database code - the "guts" of the data processing - shouldn't need to know anything about the DBMS. I don't agree with this. Received on Thu Jun 01 2006 - 13:58:07 CEST