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

From: Bart Wakker <bhawa_at_web.de>
Date: Sun, 04 Jun 2006 11:40:04 +0200
Message-ID: <87mzctjm2z.fsf_at_bhawa.web.de>


frebe73_at_gmail.com writes:

>> 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.

I doubt that in any system of significant size, either the DBMS or the application code/language is going to be replaced.

However: the DBMS may be accessed by more than 1 system/language.

Part of the application code may used in more than 1 system (i.e. used as a library).

For both reasons it is good to decouple as much of the application code from the DBMS.

If you ever need to make structural changes to your data model inside the DBMS, changing your applications is easier.

And it is well possible to reuse your application code in different circumstances, in systems with different data models and even in systems using other kinds of data storage (i.e. accessing through corba, ldap, etc.).

> The (possible) future replacement for SQL (and the relational model)
> will probably be something that are very hard to imagine at the
> current moment. If we design an interface between the database and
> the application today, it is not likely that it will fit the next
> generation architecture. I have seen old applications using index

It is likely that the data model in a particular system changes somewhat over time. Even small changes may lead to enormous effort if your SQL is spread all over the place. Also with less decoupling, changes in your application itself may easier cause the need for modifying your data model. Not all changes can be hidden behind views, sometimes a one-to-many relation may be changed into many-to-many due to new business logic for example, or an attribute may need to be changed into a one-to-many. For example your client used to have only a single domicile, now a client might have multiple domiciles in the future. Even such small changes cannnot be hidden behind views. Received on Sun Jun 04 2006 - 11:40:04 CEST

Original text of this message