Re: Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

Manual Lemos Wrote: > If you want to resort to non-portable database programming, just stick > with the native database API that PHP offers and you will get all the > speed that is possible. Using a database abstraction that does not offer > portability and still adds execution overhead does not make much sense. > Your programs still need to be adapted to run with different databases > and they will still be slower than using the native PHP database APIs. I don't think portability in database programming is as categorical as you suggest. The fact that you have gone for 100% portability may be what makes you put other abstraction layers into the non-portable camp. The fact is that if you are only doing some basic select, update, insert stuff you can probably speed up your porting of database programming code from one db to another - in other words, get some db abstraction benefits even though PEAR can not claim to offer 100% portability accross different platforms. I, for one, don't use triggers, blobs and some othr features that are non-portable in PEAR, but since I don't use them the fact that they are non-portable in these areas does not make a difference to me - it maintains the illusion of being a database abstraction layer for most situations I use it for. I think it is important to capture this observation and convey it to new users some how. I am all for using precise language when characterizing the point of a purported DB Abstraction layer. It may be true that PHP only has one true DB Abstraction layer and that is Metabase. If that is the case, then I think we should not call PEAR DB a database abstraction layer if it confuses this important distinction. A Unified API is probably a more accurate term as was suggested before. If you want to claim that PEAR DB is more than a Unified API than I think we need to perhaps develop some special terms to describe to what extent and under what conditions it can act as a database abstraction layer. We might talk about PEAR meeting Level 1 Standards for supporting portable database programming where Level 1 Standards describes that situations where you can currently use PEAR DB as a database abstraction layer. If you require Level 2 then you will need to move to Metabase. Is there any set of terms to describe levels of portability in db programming in the same way as we might talk about degrees of normalization? Regards, Paul Meagher