> >Now for the $15,000 question: does anyone else agree with this ? If > >PEAR::DB is not abstracting the database what is the purpose of such a > >library ?
I would suggest that Alexander's list of reasons for using PEAR:DB should be written up in some introductory section to the manual for PEAR DB along with some comment about the difference between a Unified DB and a Database Abstraction Layer (based on some of Manual's remarks on the difference and pointing to Metabase as an alternative for the latter). > a) unifed API > You havn't to think about the name of the command to send a query, > connecting... I agree. I think it is a Unified API where a Unified API is defined as "a common interface to connect to a db, execute queries, fetch the result and report errors". > b) it offers helpful functionality > I.e. don't care about quoting and escaping in SQL-Statments, the query command > does it for you. PEAR:DB contains different possibilties to access the result > set... (Yes you can write such functions too, but why recreate the wheel?) I agree. Where "helpful functionality" is defined as: 1. Deals with quoting and escaping of SQL-Statements 2. Provides different access methods for result sets 3. Provides an array of error trapping and error reporting features for debugging 4. Provides higher level constructs for connecting to a db, issuing queries, and accessing result sets 5. Provides a studly caps API for connecting to a db, issuing queries, and accessing result sets 6. Add your own to this list.... > c) _helps_ to keep portability > You have 'only' to change the SQL-statments, not the functions. I agree again. IMO, comments like these would be helpful in the intro to PEAR: DB. T Cox raises the point that we might be defining PEAR:DB into a corner where all it really consists of are features that are useful to developers. While I agree with that sentiment I also think it would be helpful if the there were some explicit remarks about what PEAR:DB currently offers to the web developer community. Saying that it consists of features that are useful to developers doesn't convey much to someone who is wondering whether to use it or not - it is not an actionable comment. At some point a long detailed article also needs to be written about what portable database programming really consists off. It would also be good to have a FAQ that deals with some of the work arounds that you need to use to deal with portability issues. For example, what if you rely on the autoincrementing feature in MySQL but Postgresql doesn't support it? What work around causes the least amount of reprogramming of db code when you switch from using MySQL to PostgreSQL for example. Regards, Paul Meagher > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > To contact the list administrators, e-mail: [EMAIL PROTECTED] > > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
