|
With the PEAR::DB classes you can avoid: re-writing frequently used routines to suit different
vendors' databases, or the time-consuming process of building your own wrapper functions.
DB is a database abstraction layer providing:
- An OO-style query API
- Portability features that make programs written for one DBMS work with other DBMS's
- A DSN (data source name) format for specifying database servers
- Prepare/execute (bind) emulation for databases that don't support it natively
- A result object for each query response
- Portable error codes
Drivers for the following extensions pass
the complete test suite and provide
interchangeability when all of DB's
portability options are enabled:
fbsql, ibase, informix, msql, mssql,
mysql, mysqli, oci8, odbc, pgsql,
sqlite and sybase.
Why abstract your database code?
Because often there's no reason why that useful section of code can't be reused
on other database servers. Whether it's a ten line algorithm you spent half a
day on, or a ten thousand line monster you just know you will need to migrate
someday from MySQL to Oracle or PostgreSQL. You might also develop on one database
server while targeting several production servers from different vendors.
It makes good sense to avoid replacing all the database specific functions
and routines by using an abstraction layer between your code and database
vendor specific functions.
Does that sound like a good idea? I thought so. One way to achieve this is to build wrapper scripts to
hide the real access functions from your programs. Building a library of these wrappers to support all
the functions of supported databases in the PHP API is a really big nasty project. Fortunately most of it has already been done, and is available via the PEAR repository, included in recent PHP releases by default.
Does that sound like a good idea? I thought so. One way to achieve this is to build wrapper scripts to hide the real access functions from your programs. Building a library of these wrappers to support all the functions of supported databases in the PHP API is a really big nasty project. Fortunately most of it has already been done, and is available via the PEAR repository, included in recent PHP releases by default.
By using PEAR::DB and a simple configuration script, you can avoid much of the database function related hassle associated with migrating scripts. You also get access to a comprehensive, standardized error handling system, and several functions not yet available in some of PHP's individual database APIs (like prepare() and execute()).
So, what do I need?
So, what do I need?
First, you need to be familiar with at least one of PHP's sets of database access functions,
it doesn't matter which group (MySQL, Oracle, PostgreSQL, …).
Second, you will need access to a PHP build which includes PEAR. If you can execute
<?php require_once 'DB.php'; ?> without an error then you are good to go
(Windows users may need to add the PEAR path to their php.ini file, the PEAR FAQ explains this).
PEAR::DB only helps abstract access to the database, it cannot abstract SQL statements.
For accurate information about what each supported database is capable of, implemented in
PEAR, and tested for, read the document at your pear_base_dir/DB/STATUS.
|