[nycphp-talk] if you were teaching PHP...
tgales at tgaconnect.com
Wed Jan 19 10:26:52 EST 2005
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
> > > the java route, where database transparency was one of the main
> > > (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,
> > 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
> 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'
More information about the talk