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/?[EMAIL PROTECTED]
--
E-mail: [EMAIL PROTECTED]
URL: http://www.mlemos.e-na.net/
PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
--
--
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]
