Hello,
On 09/26/2002 02:11 AM, Rasmus Lerdorf wrote:
> No DB abstraction layer, including MetaBase offers true database
> abstraction. No layer will make stored procedures portable. No layer
Not that you know, of course.
> will make your fancy Oracle DECODE() query portable. No layer will
> magically make your MS-SQL triggers work anywhere else.
If you intentionally use database specific resources that can't be
mapped to any other database, obviously your applications will never be
portable no matter what.
> 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.
This is not true. You do not have to write database specific code for
complex database work.
Have you ever heard of Siebel? Yes, the CRM (and other things) suite,
probably the best in the market. FYI, it does not use any things like
stored procedures or triggers. All the business logic is handled off the
database server.
> 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.
Nobody stops you from doing that with any underlying database
abstraction . The problem if that if you are going to write your data
layer functions in a middle to large size application and optimize them
for each database, your will take an absurd amount of time that it is
not realistic to wait for and your projects obviously will fail missing
any acceptable deadlines.
In the real world, data type abstraction like Metabase and JDBC do, or
auto-incremented sequence abstraction like Metabase does and JDBC
doesn't are highly desirable features by many developers in database
abstraction layers that really speed up their work with acceptable
performance compromises.
Either Metabase or JDBC let you use database specific SQL but then it is
up to you handle portability in your application. As a matter of fact,
people that want to take the absolute best of database applications, do
not use SQL at all, they use flat file databases, like many search
engines do. So, whoever resorts to SQL is already assuming some
performance compromises.
Regards,
Manuel Lemos
>
>
> -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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
