NYCPHP Meetup

[Mitch Pirtle]

On Tue, 18 Jan 2005 16:04:41 -0500, Hans Zaunere <lists at zaunere.com> wrote:
> 
> Those who know me know I don't favor DB abstraction, so this will be biased, and frankly I don't know that much about PEAR::DB.  Can it support prepared statements?  Can it support cursors (server side)?  Can it support collation? etc...

Sounds funny coming from a MySQL guy. (rimshot)

> While DB abstraction can be useful for simple apps, and is something worth learning about, large applications never use generic abstraction, since they are rarely deployed on multiple databases.

All I can tell you is that after working on sites that get 10 million
visitors daily, had I coded anything to a native API the whole thing
would have died a horrible death!  When you are really pushing the
limits, native APIs are what kill you, not save you - as you end up
worrying more about scaling and redundancy, where a more generic
communication-presentation-application-data layered approach will save
your bacon time after time. Something like:

  Load Balancers <=> Webservers <=> Application Servers <=> Databases

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.)

If you implement an application that maxes out mysql's functionality
for example (mitchy bites tongue), you are then going to lose a lot of
effort if you decide to put SQL Relay in front of your database
servers. Ok, maybe not logical for MySQL, but for something like
Oracle (where OCI connections have lots of overhead) this progression
happens frequently, and apps end up getting partially rewritten in
order to decouple the logic from the database layer to accomodate the
connection pool...

> That said, abstraction within the application - that is, "custom" abstraction written specifically in the application, and for their database - can add a lot of value, since it can expose the needed features for that db/app combo.  Lastly, knowing how a database works, and thus how to talk to it in the most efficient manner, is central in a successful and scalable application.

The first sentence is dead on, and Mambo's database class is a good
example. Still native MySQL calls, but nice abstraction to make the
interface simple and predictable for 3rd party developers.

Knowing how databases work is *critical* to learning how to write
useful software, as poorly-designed applications are also difficult to
maintain, let alone scale.

Which does bring up a great debate - where do you draw the line
between portability and native functionality?  If you have PostgreSQL
or Oracle, then does it make sense to load up all of your DML into the
database as stored procedures, for example? I used to think that way,
but also was convinced at the time that there were limited options on
the database server side; and now that is just not the case, with
PostgreSQL and Firebird around (and yes, even MySQL is catching up
with 5.0)   ;-)

Ditto for the HTTP layer - do you write some apache modules for speed,
or just keep everything in available (and portable) environments such
as PHP/python/etc.?

-- Mitch