PDO Introduction
PHP is primarily done by volunteers, although there are a few fixed "core" developers, but none of us are developing PHP on a full-time payroll. In addition, we are located in different parts of the world, you can imagine the long-term development of the coordination work is how difficult. Therefore, PHP is mainly based on the whim of the individual short-term needs to develop, Beijing office is also a variety of reasons, some experiments, and some are because "tomorrow has a job to pay." Although this usually improves PHP in every step, it is lack of integrity in the long run-database expansion is an important example HKRFP.
There is no real consistency between the various data extensions (OCI, MySQL, PostgreSQL, MSSQL, etc.), and even in some cases there is no real consistency within those extensions. Almost all of these extensions perform the same kind of tasks using different code that is tightly linked to the underlying database APIs. And because we have very limited staff (PHP core developers and extension developers), this makes the code more difficult to maintain, which poses a big problem for PHP.
As PHP became increasingly popular and successful, defenders 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 of the goals of database access in PHP:
? Provides a lightweight, clear, and convenient API
To unify the common features of various RDBMS libraries, but not to exclude more advanced features.
? provide an optional degree of abstraction/compatibility through PHP scripts.
We have proposed the concept of this PHP data object (PDO) because we want to get some of the more outstanding performance of the API through the use of Zend Engine 2 (The core of PHP 5). Beijing Cleaning.
The concept of the data abstraction layer in PHP is not new at all; querying PHP database abstraction in Google will find about 83,200 matches. It's almost the dream of many PHP developers, and its generation is partly due to our incomplete APIs. If you've ever tried to do anything really important with a Third-party abstraction layer, you'll often find that the abstraction layers are too powerful for the job at hand--either as a significant amount of learning before use, or as a slow interface, Parameters require multiple script function calls to reach the database's own API; there are usually two of these appearances.
Why do these layers of abstraction have this problem? These layers of abstraction are always trying to accomplish too many tasks, possibly even impossible tasks. We decided to target practicality, using only some of the most common database API features as our foundation, and enabling PDO drivers to expose their product-specific features to regular extension functions.
Why use PDO?
Most people who have heard rumors about database abstraction extensions are immediately puzzled by the expansion of PDO-do we want to parse SQL and convert it to the corresponding back-end dialect? How we deal with feature X or attribute Y, and so on. So it might be a surprise to hear that we don't have to worry about it at all in the PDO, we don't want to make everything uniform, because to make it possible, it's only to limit ourselves to the lowest common standards.
If PDO is not a monolithic abstraction layer, is there any other reason why you should consider using it?
Performance From the outset, PDO learned from the successes and failures of existing database extensions. Because PDO's code is brand new, we have the opportunity to restart design performance to take advantage of the latest features of PHP 5.
Ability PDO is designed to provide common database functionality as a foundation, while providing easy access to the unique features of the RDBMS.
Simple PDO is designed to make your database easy to use. The API does not force you into your code, and it clearly indicates the procedure for each function call.
? can be extended at run time. The PDO extension is modular, enabling you to load drivers for your database backend at run time without having to recompile or reinstall the entire PHP program. For example, the PDO_OCI extension implements Oracle database APIs instead of PDO extensions. There are also a number of drivers for MySQL, PostgreSQL, ODBC, and Firebird, and more drivers are still in the process of development.
You might want to see how PDO compares with other common abstraction layers, such as PEAR DB or ADODB. PDO is lighter than other common abstraction layers, both in terms of APIs and performance, but it involves providing uniformity across the backend of each database, rather than those layers of abstraction, such as the PEAR MDB 2 abstraction layer for handling a large number of portability issues.
Where can I get PDO?
PDO is provided through PECL (pronounced "pee-kle", European language Style), or PHP extension library. If you are running a Linux computer, set it up as described in the following instructions, and later install details on Windows.
Note that the PDO and its drivers are currently in Alpha State; This means that we can reasonably guarantee that there are no major flaws, but the package is not functional-we also need to add a lot of functionality. Although we encourage you to test the package, it is not recommended for production at this stage.
