Skip navigation.

Having your cake, and abstracting it

One of the benefits of being politely kicked off the weblogs.com domain is that I have been inspired to post more frequently. I used to post maybe 3 times a week. Now it appears that I'm doing it everyday. I intend to slowdown some time and get a life, but I always get motivated whenever I think about the recent weblogs.com controversy.

Recently there was a debate on database abstraction and database access. The key point people were saying is that database abstraction slows things down, because it tries to make every database look the same. Database access is ok because it just provides essential database features, with a light icing of error-handling, debugging and monitoring facilities, etc.

I think good design means designing stuff in a modular and layered fashion. We layer the software to provide different levels of abstraction. ADOdb is a popular database abstraction library for PHP that I designed. Now there is a secret recipe that is completely open in ADOdb. Let me explain: ADOdb provides both a database access layer, and a abstraction layer. They are separate layers.

ADOdb provides lots of common data access facilities, such as error handling, smart transactions (nested transactions), cached recordsets, transparent LOB handling, which are generally useful, whether or not you are thinking of porting to multiple databases. These are things you need to manage your data access, whether you connect only to MySQL, or to 10 different databases.

At the same time, ADOdb makes no attempt to be an abstraction layer in the base driver classes.

 BASE ACCESS CLASSES

 adodb -+
        +-- odbc
        +-- oci8 
        +-- mssql
        +-- mysql
        +-- postgres64
        +-- ibase
        +-- sqlite
        +-- (other drivers)
 

So if you run the oci8 and mssql drivers, their performance is good, but their behaviour is different because we don't code abstraction slowdowns.

Instead, all (ok, ok, most) abstraction specific slowdowns are placed in the derived portability classes. For example, the oci8po and mssqlpo classes below provide abstraction services. The "po" suffix indicates portability later. This means that the oci8po and mssqlpo drivers really do behave in a similar fashion.

 BASE ACCESS CLASSES     ABSTRACTION CLASSES/
                            PORTABILITY LAYER

 adodb -+
        +-- odbc       ---+ odbc_mssql
        |                 + access
        |                 + vfp
        |
        +-- oci8       ---- oci8po
        |
        +-- mssql      ---- mssqlpo
        |
        +-- mysql      ---- maxsql
        |
        +-- postgres64 ---+ postgres7
        |                 + netezza
        |
        +-- ibase      ---+ firebird
        |                 + ibase_borland
        |
        +-- sqlite     ---- sqlitepo
 

Now the developer using ADOdb has a choice. For oracle, you can damn speed, bless portability by using the oci8po driver; or you can say damn all abstraction layers, bless adodb by using oci8.

So its true that ADOdb is a big package. But that's because it is actually made up of many tiny drivers designed for optimal use. A bit like loop unrolling optimizations that make your code larger, but run much faster. I suspect that ADOdb has more database drivers that any other similar PHP library for this reason (39 when I counted today).

Another point is that people seem to think that abstraction libraries have to be slow. I suspect it's because they haven't looked carefully into it, and due to inexperience by some library authors. ADOdb is the 3rd or 4th db abstraction library I have written.

Most of the overhead is data access issues which you will alway have, whether or not you are concerned with database portability. There really is very little difference between ocilogon and mysql_connect, or ocifetchinto and mysql_fetch_array, except for the names and order you pass in parameters.

I hope this explains why ADOdb continues to have a good reputation for performance, with published benchmarks. Classes do provide a powerful way of abstracting functionality, and a careful layered design really means you can have your cake and more.