Re: PEAR DB documentation?

Hello Dean, On 01-Apr-01 07:33:02, you wrote: >I've used DB in the past, but since I'm writing a public-use app, I thought >I'd use metabase, since it's DBMS-independent. DB seems to be the more >traditional way of using database abstraction layers (as in Perl DBI and >such); the interface is DBMS independent -- whether the SQL you write is >DBMS-independent is another story. Metabase provides for means for making >your SQL DBMS-independent, so it's really quite another step beyond >traditional database abstraction. That's right. When it comes to database application portability, maybe the only thing that comes close to Metabase is Java JDBC. Even when compared with that, Metabase offers features without parallel that are very important for Web applications like: - Auto-incremented sequences: objects that store integers and return incremental unique values on demand. It's very important for databases with fields with unique indexes, primary keys or other unique integer values. In databases that do not support real sequence objects (like MySQL), auto-incremented fields are used, but the API is always the same. - Select row ranges: lets you specify a range of rows (start, limit) that you want to retrieve from a select query. It's very important to display query result listings split in pages with a limit of displayed rows. It's like MySQL LIMIT clause, but it works with all databases supported by Metabase. >However, you seem to lose /a lot/ of features of whatever DBMS you use if >you use metabase. It supports few data types (domains), and it doesn't >support specifying primary keys or references. I'm trying to see if I can >get by without them. This is not accurate. Metabase supports the following data types: text, boolean, integer, decimal (fixed point), float, date, time, time stamp (date and time). Some databases do not support some of these data types, but Metabase emulates them for you. So, it's not like you lose a lot of features, but rather you gain some that you wouldn't if you do not use Metabase. >If you're using an abstraction layer b/c your app may need to be reused with >a different DBMS than you're currently using, metabase may be a good choice; >however, if you're guaranteed you'll always use the same DBMS, I'd use >PEAR's DB. Much simpler. PEAR DB is simpler because it lacks many features that Metabase provides. The features that Metabase has in addition are highly desirable in particular for Web development. If you don't miss those features now, chances are that you may miss them sooner or later. PEAR DB developement was started much later than Metabase's, so PEAR DB is less mature. When PEAR DB development reaches the maturity of PEAR DB, it certainly won't look that much simpler. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --