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

> > 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?
> That's a different question. Maybe the customer ordered us to put Y in a
> flat file, so they can write on it with their favorite text editor.

If you are a honest consultant, you should tell your customer to buy a good database front-end such as TOAD. If he still want to use his text editor, learn him to use the import/export features of the database. If you want to make money, tell your customer to let you implement a flat file version, it will only cost him a million dollar.

> The question is How to encapsulate the business logic so such decisions are
> less relevant to it.

If there are no good reasons for encapsulation, you should not do it.

> > That is why we use common interfaces such as JDBC/ODBC/ADO.
> Those are wide generic library interfaces. Once we have them, we trivially
> encapsulate them again, into narrow application-specific interfaces. We take
> one more step towards programmer-friendliness because those wonderful
> libraries can't.

The only reason why JDBC/ODBC/ADO may not be considered programmer-fiendly, is the use of SQL statements as strings, and the poor IDE support. If you want a programmer-friendly solution, use embedded SQL (such as SQLJ) instead.

By the way, your original statement was: "If you need data, you should get it from whatever system, thru a common
interface."
Now you are suddenly talking about application-specific interfaces.

> > So you agree that in this example, decoupling the SQL statements would
> > not make the change easier?
> Gee, much of the decoupling will already occur at the generic library
> interface.

But in this example decoupling will not help you.

>So how about _this_ change:
> client(clientid, ...., domicile) -> client(clientid, ...., domicilio)

I assume you just rename a column without changing the semantics? If you really want do such stupid change, I would suggest using the Search&Replace utility in your IDE. One other option is to use constants for table and column names, while building your SQL statements. If you want to change a column name, just change the constant definition.

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