On 09.10.2005 08:48, andrew wrote:
> A very usual and smart approach is to use clases in PEAR::DB.
Well, IMHO PEAR::DB is one of the worst classes of PEAR. Besides its
ugly code it's worth nothing. This is some incomplete "abstraction
layer" for kiddies, to make it easy for people coming from stupid
storage engines like MySQL or SqLite, to _store_ their data in another
DBMS.
I never really understood, what such a thing should be good for. SQL
implementations are not portable, nor are stored procedures, functions,
rules, triggers, etc. Every DBMS implements them in it's own way and
almost all professional devs will implement most, or at least the
critical parts, of the business logic directly inside DBMS and not at
application level. Thus making the application basically just a
frontend, calling stored procedures and writing to views, controlled by
triggers and strict permissions.
The only thing PEAR::DB might be usefull for is, writing those famous
cross-dbms-apps, which basically use the DBMS highly inefficient as a
better plaintext file (not even using foreign keys in most cases, so it
will work with MySql 3.x as well).
And if you don't what to write such bizarre cross-dbms-apps, what is the
point in using PEAR::DB at all? Those few incomplete methods wrapping
the pg_* functions in some highly debatable way?
Do yourself a favor and write your own slime and efficient set of
classes around the native API-functions of your DBMS. PEAR::DB and
others prevent you from using an advanced DBMS the way you should.
--
Regards,
Hannes Dorbath
