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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
