NYCPHP Meetup

[Tim Gales]

David Mintz writes

> On Tue, 18 Jan 2005, Hans Zaunere wrote:
> 
> > > [Mitch wrote ...]
> > > As a matter of fact, the biggest site I ever worked on ended up 
going
> > > the java route, where database transparency was one of the main 
goals.
> > > (Not my decision as I had moved on, but you get the point.)
> >
> > Quite true, and frankly, Java kind of has the best of both worlds.
> > JDBC drivers are "abstractions" but written particularly for that
> > database, ie, they expose the same interface but are native calls
> > themselves.  It's a totally different layer of abstraction than, 
let's
> > say, PEAR::DB.
> >
> 
> This may be a naive question, but, well... Do you suppose PEAR::DB is
> written the way it is (rather than more like JDBC) because PHP 4 
doesn't
> support the notion of interfaces? I

They are two different things. PEAR is a framework.
PEAR::DB provides a layer of abstraction which can 
mask the idiosynchracies of the underlying SQL syntax(es).

PEAR:DB has to fit in with the PEAR structure -- 
how it handles errors etc. (some of the framework, in my 
opinion, tries to make up for the deficiencies of the PHP 4 object 
model -- which may be what you said).

JDBC, on the other hand, provides a connection to a 
database with a subset of functionality.

So PEAR:DB can help to make SQL statements portable.

JDBC, on the other hand, makes the data itself portable 
by offering a lobotomized wersion of SQL to databases 
which support a JDBC connection.

T. Gales & Associates
'Helping People Connect with Technology'

http://www.tgaconnect.com