No DB abstraction layer, including MetaBase offers true database
abstraction. No layer will make stored procedures portable. No layer
will make your fancy Oracle DECODE() query portable. No layer will
magically make your MS-SQL triggers work anywhere else.
For any moderately complex database work, you are going to have to write
database-specific code and if you are doing that you might as well cut out
the middle-man and use the faster direct DB calls.
My standard approach is to do functionality abstraction. Stuff like,
get_user_record(), update_scores(), etc. Implement these functions for
each database you wish to support and stick them in separate include
files. Then include the appropriate set based on a config setting so the
user can switch the app between the supported databases.
-Rasmus
On Thu, 26 Sep 2002, Manuel Lemos wrote:
> Hello,
>
> On 09/24/2002 11:15 AM, Joshua E Minnie wrote:
> > I was reading an article at PHPBuilder.com (not very recent, 01/15/2001)
> > about PEAR DB, and was wondering if anyone had any experience using PEAR
> > rather than the functions dedicated specifically to each type of DB (i.e.
> > mysql_, mssql_, pg_, msql_, etc.). Also, if anyone has any reasons why to
> > go with one or the other.
> >
> > The reason I ask, is because I recently downloaded QuerySim so I could
> > simulate my db info while the db is still in development and not have to
> > slow down the process. QuerySim uses PEAR DB functions, and after the db
> > development is finished it is an easy conversion. Simply change the line
> > that tells which db is being accessed.
> >
> > [code snippet]
> > $db = DB::connect( "mssql://$dbuser:$dbpass@$dbhost/$dbname" ); // for MSSQL
> > $db = DB::connect( "mysql://$dbuser:$dbpass@$dbhost/$dbname" ); // for MySQL
> > //instead of
> >
> > $conn = DB::connect('querysim');
> > [/code snippet]
> >
> > And my querys would still remain relatively the same. I hope you can shed
> > some light on this because I am not really sure which one to use.
>
> No PEAR-DB does not guarantee true database portability. Among other
> things, think about for instance date and time fields that are formatted
> differently between databases. PEAR-DB does not assure that you only
> deal with a single format, so you would always have to handle eventual
> differences in format representation in your application which is what
> you want to avoid.
>
> If you are looking for true database portability, you may want to look
> at Metabase which is a much more mature database abstraction package
> that not only deals with data type representation format differences to
> make your database applications really portable, but it also manages
> your database schemas so you don't have to write database specific SQL
> scripts to create tables and other database objects.
>
> All you need to do is to specify a schema in a database independent
> format based on XML and Metabase creates any tables, fields, indexes,
> sequences for you.
>
> Metabase is Open Source and you may find it here:
>
> http://www.phpclasses.org/metabase
>
> --
>
> Regards,
> Manuel Lemos
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
