Posted by David Haynes on 01/01/06 14:00

Balazs Wellisch wrote:
>> This way, I can change database factories (to connect to different
>> databases) with ease and, since the interface implementation contains all
>> the SQL, there is only one file I need to scan to adjust for the variances
>> in the SQL languages. (e.g. limit 1 in MySQL vs. count = 1 in Oracle)
>>
> Hmmm, ADODB already takes care of that for you. It also deals with date
> formatting and other issues. Plus it provides useful features like caching
> and SQL logging. Why reinvent the wheel?
>
> Balazs
ADOdb is an example of an abstract database factory, as is PEAR DB. It
was not my intention to imply that there was a need to write the
factory, just that it was a good idea to isolate the concept of the
factory from the concept of the SQL code driving the factory, and, in
turn, to isolate the SQL code from the rest of the application space.
Sometimes, due to the databases I am talking to and the in-house
standards in place, it is necessary to write my own factory. This does
not diminish the advantages of the two abstraction layer model.

In other OO languages, Java for example, it is common to have a caching
database factory and a database bean - which is an interface
implementation - that contains the SQL code for the application.

-david-

[Back to original message]