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

From: Bart Wakker <>
Date: Sun, 04 Jun 2006 14:10:49 +0200
Message-ID: <> writes:

>> If you ever need to make structural changes to your data model
>> inside the DBMS, changing your applications is easier.
> Do you have any examples of strucutal changes in the data model that
> could be easier to solve using a decoupled strategy?

Any real examples would require way too much space. However you should be able to imagine that it is much easier to adapt for data model changes is easier if the data access is done in a small and confined part of your application.

>> 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.).
> You want to use the same application with different data models? Do you
> have any example of this? The data models need to be pretty similar
> anyway, or?

No, I mean the data model may change. The same code may be fed with (the same) data, but stemming from different origins, even coming from a different kind of origin. You just need to adapt the original data to fit what is needed by your code.

> The type of protocol (Corba, RMI, DCOM, SOAP, whatever) that is used,
> can easily be hidden without hiding the SQL statement. For example,
> then you use Oracle JDBC driver, the sqlnet protocol is not visible to
> you.

Yes, you could declare JDBC to be the universal API to hide any data access, and access corba, rmi, ldap all through JDBC. The question is if that is wise. It would be better to hide it behind an API that fits more naturally in the environment (java in this example, so rather using Interfaces).

>> It is likely that the data model in a particular system changes
>> somewhat over time.
> Indeed.
>> Even small changes may lead to enormous effort if
>> your SQL is spread all over the place.
> The most common change, adding columns or tables, will lead to 0
> effort. Removing columns or tables will of course be more difficult,
> but can you give some examples of how such change would be easier to
> handle if you decouple the SQL queries?

Especially changing the nature of relations may be painful, as my example where a single domicile attribute is replaced by a list of possible domiciles. Removing columns can usually be hidden through views emulating the removed physical column.

>> Also with less decoupling,
>> changes in your application itself may easier cause the need for
>> modifying your data model.
> Do you have anything to support this claim?

Nothing but my personal experience and guts feeling, which admittedly may not be very convincing using this medium.

>> 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.
> If the business logic change, the database schema might need to
> change too. What is your claim here? Both the business layer and
> database is touched. Such change can by definition never be
> isolated.

Sometimes you can defer change to the business layer or parts of it. By isolating data access this becomes a possibility.

>> 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.
> It can't be hidden behind a OO API either? The business rules has
> changed, and it effects all layers of the application, all the way from
> the database to the GUI. Using a decoupled strategy, such change would
> be much harder to do.

Not necessarily. As a contrived example, maybe parts of the application only reading the domicile might be fine if they get the (single) one wich comes alfabetically first. You would not have to touch these parts if you have external data access code which simulates the continued existance of a single domicile attribute. Received on Sun Jun 04 2006 - 14:10:49 CEST

Original text of this message