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

From: <frebe73_at_gmail.com>
Date: 4 Jun 2006 10:07:54 -0700
Message-ID: <1149440874.060341.222670_at_i39g2000cwa.googlegroups.com>


> Could you state back the claim you feel is unsupported?

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

> Per the general thread, it means maybe data X comes from a DB, and data Y
> comes from a flat file, and they both come thru the same interface, so the
> business logic that adds value to them can't tell where each came from.

What are the benefits doing this? Why would you use flat files if you already have a SQL implementation? Why would you use SQL if you already have a flat file implementation?

> If you need data, you should get it from whatever system, thru a common
> interface. The alternative taints business logic with runaway dependencies.

That is why we use common interfaces such as JDBC/ODBC/ADO.

> > 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.
>
> Right. Most libraries are closed for modification and open for extension -
> along certain lines.

So you agree that in this example, decoupling the SQL statements would not make the change easier?

Fredrik Bertilsson
http://frebe.php0h.com Received on Sun Jun 04 2006 - 19:07:54 CEST

Original text of this message