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

> Any real examples would require way too much space.

You are free to send pointers to another website if you want to. Unsupported claims are not very useful.

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

If you have the same data stemming from different orgins, just put the database connection string into a configuration file. What do you mean with "different kind of orgin"? Like relational, network, hierachical?

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

Corba and RMI are a protocol for inter-process communication. LDAP is a protocol for a hierachial directory service. They are totally different things. Corba and RMI may be used for communication between a client computer and a database server or any kind of remote service. LDAP can only be used there the the remote service is a hierachical database/directory of some kind.

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

Indeed it isn't.

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

But in this scenario the change is initated by "new business logic". If the the business logic change, I assume that the business layer change too.

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

Lets say the original table looks like this: client(clientid, ...., domicile)

Your change need a new table:
client_domicile(client, domicile)

Because there still are some kind of default domicile (the first in alfabetical order), the client table is not changed. Your change consist of adding a new table, which don't affect the old SQL statements at all. Unless you want to use the new 1:M relationship, you don't have to change to application at all.

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