PHP 5 Data Object (PDO) Abstraction Layer and Oracle

PHP 5 Data Object (PDO) Abstraction Layer and Oracle_PHP Tutorial

WBOY

Release： 2016-07-20 11:07:20

Original

754 people have browsed it

The original

developer of the MingxinPHP DataObject (PDO) data abstraction layer gives you a brief introduction to the abstraction layer, focusing on running it with Oracle situation. Requires PHP: 5.0
Requires others: Oracle 8 or higher client library
Download PDO for Oracle (Windows): php_pdo.dll, php_pdo_oci.dll
Download for Oracle PDO (Unix): pdo, pdo_oci
PDO Introduction
PHP is primarily a volunteer project; although there are a few regular "core" developers, none of us are working full-time on a paid basis to develop PHP. . Add to that the fact that we are located in different parts of the world, and you can imagine how difficult it can be to coordinate long-term development. Therefore, PHP is mainly developed based on whims of personal short-term needs. The reasons are also varied, some are experiments, and some are because "there is work to be handed in tomorrow." While this often improves PHP every step of the way, it lacks completeness in the long run - the
Database Tutorial extension is an important example. There is no real consistency at all between the various data extensions (oci,
mysql, postgresql, mssql, etc.), and in some cases even There's also no real consistency within these extensions. Nearly all of these extensions accomplish the same kind of tasks using different code that is tightly tied to the underlying database API. And because we (PHP core developers and extension developers) have very limited manpower, this makes the code more difficult to maintain, which creates big problems for PHP. Due to the increasing popularity and success of PHP, the maintainers of the major PHP database extensions attended the LinuxTag 2003 conference in Germany, where we exchanged views on the future of PHP. When discussing the randomness of PHP development, we identified some goals for database access in PHP:
· Provide a lightweight, clear, and convenient API
· Unify the common features of various RDBMS libraries, But more
advanced features are not excluded. · Provides an optional greater degree of abstraction/compatibility via PHP scripts.
We came up with the concept of PHP Data Objects (PDO) because we wanted to gain some of the advantages of this API by using the advanced object-oriented features of
Zend Engine 2 (the core of PHP 5) Better performance. The concept of data abstraction layers in PHP is not new at all; a Google query for "PHP database abstraction" yields around 83,200 hits. It's almost a dream come true for many PHP developers, and it came about in part because of our incomplete API. If you've ever tried to use a third-party abstraction layer to do anything really important, you've usually found that the abstraction layer was designed to be too powerful for the job at hand - or presented itself as something that needed to be used before it could be used. A lot of
learning is carried out, or the interface speed is slow, and parameters need to be called through multi-layer scriptsfunctions to reach the database's own API; usually the above two symptoms exist. Why do these abstraction layers have this problem? These abstraction layers are always trying to accomplish too many tasks, perhaps even impossible tasks. We decided to aim for practicality and just base ourselves on some of the most common database API features, and enable PDO driver programs to expose their product-specific features as regular extension functions. Why use PDO? Most people who have heard rumors about database abstraction extensions will immediately wonder about the extension aspect of PDO - do we need to analyze SQL and convert it into the corresponding back-end dialect? How do we deal with feature X or feature Y, and so on. So you might be surprised to hear that we don't worry about this at all in PDO; we don't want to make everything completely unified, because the only way to make that possible is to limit ourselves to the lowest commonality standard.
If PDO is not a monolithic abstraction layer, is there any other reason why you should consider using it?
　·Performance. PDO learned from the beginning about successes and failures in extending existing databases. Because PDO's code is brand new, we have the opportunity to redesign performance from the ground up to take advantage of PHP 5's latest features.
　·Ability. PDO is designed to provide common database functionality as a foundation while providing easy access to the unique features of an RDBMS.
·Simple. PDO is designed to make working with databases easy for you. The API doesn't force its way into your code and makes it clear what each function call does.
　·Extensible at runtime. The PDO extension is modular, enabling you to load drivers for your database backend at runtime without having to recompile or reinstall the entire PHP program. For example, the PDO_OCI extension implements the Oracle Database API instead of the PDO extension. There are also drivers for MySQL, PostgreSQL, ODBC, and Firebird, with more in development.
You may want to know how PDO compares to other commonly used abstraction layers, such as PEAR DB or ADODB. PDO is lighter than other common abstraction layers, both in terms of API and performance, but not as well when it comes to providing uniformity across database backends, such as those used to handle a large number of portability issues. PEAR MDB 2 abstraction layer.