Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sun, 04 Jun 2006 11:40:04 +0200
>> 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.
For both reasons it is good to decouple as much of the application code from the DBMS.
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