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

From: <frebe73_at_gmail.com>
Date: 4 Jun 2006 04:25:16 -0700
Message-ID: <1149420316.174385.248820_at_y43g2000cwc.googlegroups.com>


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

Agreed.

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

I don't follow your argumentation here:
DBMS may be access by more than 1 system, and because parts of the application may be used in more than 1 system ==> Need to decouple application and DBMS???

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

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

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.

LDAP is a protocol limited to hierachial databases. If you want to able to use both relational and hierachial databases, you need to use the smallest common denominator, which means that can use almost nothing of the features provided.

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

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

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

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

Fredrik Bertilsson
http://frebe.php0h.com Received on Sun Jun 04 2006 - 13:25:16 CEST

Original text of this message