Database abstraction layers

I’m interested in hearing what other people think about PHP database abstraction layers/wrappers; and what others have chosen to use.

I started off using the one that came in PHPLib (and “sendcard”:http://www.sendcard.org still uses this) but quickly moved to “PEAR::DB”:http://pear.php.net. I chose it because it seemed to be becoming the standard and I liked the API.

Now, 2 years on there still doesn’t seem to be a standard. “AdoDB”:http://php.weblogs.com has some nice features but I don’t like the public interface (I can’t comment on the interior code as I’ve never looked at it) - the use of properties (? - forgotten the name of @$this->foo@) instead of methods never feels quite right to me.

Every time I start a new project I have another look around. Anyone got recommendations for something to use in the RSS Aggregator?

*PS:* if you’ve used PEAR’s “DB_DataObject”:http://pear.php.net/manual/en/package.database.db-dataobject.php or something similar (maybe in another langauge) let me know if you found it useful or not as I’m tempted to try it for the aggregator.

8 comments ↓

#1 Rémy on 10.15.03 at 10:54 pm

I started whith AdoDB and it is a nice compleet class, until I found Eclipse (http://www.students.cs.uu.nl/people/voostind/eclipse/)and I never use anything else anymore. It’s a clean and very simple to understand libary (look at the code!).

PEAR::DB is a somthing I dislike, because it has some serious designflaws.

#2 Peter Bowyer on 10.16.03 at 2:49 pm

Hi Rémy,

Yes, I remember coming across the Eclipse library before - I’ll take another look at it.

Now a question (which is not a personal attack): did you look at PEAR::DB yourself and discover design flaws, or just listen to other people’s comments and take them on unquestioningly? Too much of the time people seem to rely on one or two vocal members of the community who make statements, often without backing. I’d say that in many places PEAR::DB is better designed than AdoDB - which is why it is slower.

#3 Chris Neale on 10.18.03 at 12:25 am

Now, 2 years on their [sic] still doesn’t seem to be a standard.

‘Perfectionism’ clearly isn’t the watchword ?

#4 Peter Bowyer on 10.19.03 at 11:12 am

It is when I’m

# not typing entries with a lecture due to start in a couple of minutes time
# not using a pay-per-minute connection

but that mistake has been fixed now.

#5 Peter Bowyer on 11.02.03 at 9:34 am

Looks like I’ll use MDB now, as it’s almost as fast as AdoDB and has a decent API/feature set.

#6 Basil Crow on 11.02.03 at 11:05 pm

ezSQL is the best I’ve worked with:

http://php.justinvincent.com/

#7 Patrick Smallwood on 12.16.03 at 8:50 pm

Sorry to comment after you’ve decided, but I thought it might still be useful.

Over a year ago, I forked a game - Blacknova Traders - and it used adodb. I quickly changed just about every backend it used (templates->smarty, auth->md5), but adodb ended up staying.

I chose to keep adodb because quite simply, it’s great. The author (John Lim) is extremely polite, reasonable and responsive. I’ve contributed patches, found issues, and found undocumented features.

When I do find problems, he generally has them patched in the next version - generally only a few weeks later.

Not to mention, the code is incredibly robust - tons of rich features (performance monitoring, xml schema support, db-independent time and data types), with extreme speed.

Its not just a good choice - its a GREAT choice. PEAR::DB was rejected because of the difficulties with pear - not because of the strengths/weaknesses of that module.

I did however, compare with phplib, and we found a number of features that we specifically needed, and that we didnt think (at the time) that phplib did as well as adodb.

Just my experiences, hope it helps.

#8 Fu22 Ba55 on 06.10.04 at 3:14 am

I’ve been using Pear::DB_DataObject and Pear::HTML_QuickForm with great results.

Overhead is a little higher with PEAR, and DB_DataObject can be counterintutive to set up at first…

But once you start joining tables, and doing inserts… DB_DataObject is amazing. I haven’t tried ADODB (site currently appears to be down), but from glancing at ADODB’s docs in the Google cache it doesn’t look like it had anywhere near the features of DB_DataObject. Maybe I need to check the ADODB docs again.

I’m interested in ADODB because a lot of great projects endorse it… (PostNuke, DotProject.net, XRMS (Open Source Salesforce.com clone), and it seems faster, but I’m so addicted to the ease of DB_DataObject, I don’t want to switch to another abstraction layer unless it has (at least) the same features.

Am I missing something? DB_DataObject seems to outclass ADODB?

-Fu22

Leave a Comment