Write Once-run anywhere write-run anywhere this is a marketing slogan for Java, but it is also one of the key features of PHP. Many business models rely on operating system independence to ensure that products can be sold to a wide range of customer groups. So why tie yourself to some kind of database vendor? The database abstraction layer enables you to develop your application independently from the database. However, they typically have more impact on performance than you want, or they are not sufficiently abstract to eliminate all code related to a particular database. What will this article teach me? This article will have a good introduction to the database Abstraction package PEAR MDB. The focus of the article will be on the more advanced features provided by the MDB beyond similar packages, such as data type abstraction and XML-based schema management. The basic understanding of PHP and SQL is recommended. Why do you want another database class? Typically, Web engineering is added to an existing IT infrastructure after customers have determined that they want to use that RDBMS (relational database management system). Even if that's not the case with different budgets that might affect what data you choose for deployment. In the end, you as a developer may simply prefer not to tie yourself to a vendor. Since then, it means keeping versions of each supported data or sacrificing more performance but gaining more ease of use: go to the PEAR MDB. The MDB is a database abstraction layer that focuses on making an RDBMS-independent PHP program a simple process. Most of the other PHP's so-called database abstraction layers provide a common API and a very limited abstraction (mostly for sequences only) for all supported databases. The MDB can be used to abstract data sent and received by all databases on the other. Even the database schema can be defined as an RDBMS-independent format. But it provides these features while still maintaining a high level of performance as well as ease of use. This is achieved by deeply observing the two popular database abstraction layers, PEAR DB and Metabase, and then merging them. And in the fusion process, taking advantage of this opportunity to clean up their fusion API and any impact on the performance of the design. How does an MDB appear? As early as the fall of 2001, I was looking for a database abstraction package that might allow my company's program framework to be independent of the RDBMS. The goal is to reduce the number of code related to a particular database to zero. I found that the only package that provides such a feature is Metabase. But metabase has some parts because of the uncomfortable API to be compatible with PHP3. Nonetheless, we decided that Metabase was myOur only choice. But even after adding a patch of performance improvement to Metabase, we still feel that we are giving up too much performance. We met Metabase's author at the 2001 PHP International Conference, and we talked about the benefits of making something like Metabase a part of the PEAR project. Shortly thereafter, a discussion began on the possible benefits of PEAR DB and Metabase convergence on the PEAR mailing list. After a lot of discussion in our company, we decided to take on the task. After a few months of hard work, we now have the first stable release of the MDB. What does the MDB offer you? The MDB combines most of the features of PEAR DB and Metabase. In fact, the only feature in PEAR DB that no longer exists is to return an object as a result set. We give up this feature because this feature is not commonly used and the loss of performance is very obvious. Many development time is used to make the API as useful as possible. Ultimately, the MDB offers these features at least as fast as PEAR DB and much faster than Metabase. A list of these most important attributes: OO-style API pre-prepared query simulations for full data type abstraction (including LOB support) for all data that is passed in and fetched from the database Database/table/index/sequence creation/discard/change RDBMS unrelated database schema management Inherit into PEAR framework (PEAR installer, PEAR error handling, etc.) so how does it work? The MDB provides some very advanced abstraction features. It is important to remember that these features are only available for selection. However, it is important to use them when writing RDBMS-independent PHP programs. A demonstration of how simple it is to use the MDB is the "Links and Documentation" section at the end of the article. As mentioned earlier, the focus of the article is to introduce the features that make the MDB different from the other PHP database abstraction layers. You can find the code for all these example scripts in a CD that is packaged with this issue. But first we need to install the MDB. Using the PEAR installer this is actually very easy. I can't tell you the PEAR installer in this article. But I hear the next installment will discuss the PEAR framework in great detail. It is still a bit odd to have the Setup program run on Windows as though it were supported. For *nix Systems You need a CGI version of PHP installed on your system and simply run the following command: Lynx-source go-pear.Org|php after the installation is complete, you just need to enter a single line of command, then it's all done. Pear Install MDB If the previous procedure doesn't work for you, there is always an option to get the package directly from the Pear MDB home page. The URL is listed at the end of the article. Using data type abstraction because most databases tend to have some personality or quirks, it is important for an MDB to hide these differences from the developer. The MDB achieves this by defining its own internal data type: Text,boolean,integer,decimal,float,date,time,time Stamp,large objects (file). All data that is passed to the database and retrieved from the database can be converted into an MDB's internal format or converted back from the internal format of the database. The relevant example scripts in this section can be found in the datatype directory. Let's look at the following query: $session = 098F6BCD4621D373CADE4E832627B4F6; Set time out to minutes $timeout = time () +60*30; Select query showing how the datatype conversion works $query = SELECT createtime, user_id from sessions; $query. = WHERE session =. $session; $query. = and lastaccess <. $timeout; If this query is sent to the database, probably will fail. The reason is that the values stored in the $name need to be converted to the correct string format. This may mean that the contents of the $name may have special escape characters or be surrounded by quotes. PEAR DB provides a method for this db:.quote (). In the MDB this method is called Mdb::gettextvalue (). The difference is that the MDB provides such a function for each of the data types listed earlier. As a result, we are able to convert $timeout to the correct format. Convert $timeout to the MDB timestamp format $timeout = Mdb_date::unix2mdbstamp ($timeout); SELECT query showing how the datatype conversion works $query = SELECT Createtime, user_id from sessions; $query. = WHERE session =. $mdb->gettextvalue ($session); $query. = and Lastaccess <. $mdb->gettimestampvalue ($timeout); To make a presentation, let's assume I just want to get the first line. Mdb::queryrow () Obtains the first row, which releases the result set and returns its contents, so it is exactly what we want. $result = $mdb->queryrow ($query); But different RDBMS have different formats for returning data such as dates. Therefore, if we then want to calculate some data, regardless of the chosen RDBMS, it is important to return the data in the same format. This can be done semi-automatically by MDB. All you need to do is tell your results what type of column will be, and the MDB will handle the work of the conversion. The simplest way is to pass this information to the query function. $types = Array (timestamp, integer); $result = $mdb->queryrow ($query, $types); This tells the MDB that the first column type of the result set is timestamp and the second column is integer. All query functions can accept such meta-information as optional parameters. Data can also be set by Mdb::setresulttypes () afterwards. Depending on the data obtained from the database, it will then be converted to the data returned by the corresponding. The data format of the timestamps within the MDB is in accordance with the ISO 8601 standard. Other packages like PEAR::D ate can handle this format. The MDB also provides some data format conversion functions in the Mdb_date class, which can be optionally included. Because quite a number of RDBMS return integer data in the same way, it is not necessary to convert integer data. Thus, in order to get a little performance improvement you can do this: $types = array (timestamp); $result = $mdb->queryrow ($query, $types); This allows only the first column of the result set to be converted. Of course, this can be an issue if the MDB is used to return different databases of integers. However, a slight performance improvement may not be worth the risk. But again, it shows that the use of these features is only optional. ListinG 1 shows an example of using a pre-prepared query. If you have to run a large number of queries and the only difference is that the data is passed to the database, but the structure of the query is the same, which can be quite convenient. Advanced databases can store parsed queries in memory to speed performance. Listing 1 $alldata = Array (Array (1, one, un), array (2, one, deux), array (3, three, trois), Array (4, four, quatre)); $p _query = $mdb->preparequery (INSERT into numbers VALUES (?,?,?)); $param _types = Array (integer, text, text); foreach ($alldata as $row) {$mdb->execute ($p _query, NULL, $row, $param _types), and all four arrays stored in the $alldata are used for the EXECUTE statement. The data is automatically converted to the correct format. Because this is an INSERT statement, the second parameter of Mdb::execute () is set to NULL because we will not have any result columns that require us to set the data type. There are also lobs (large objects) in the supported data types, which enable us to store files in the database. Binary files are stored in BLOBs (binary large objects) and plain text files are stored in CLOB (character large objects). In the MDB, you can only store lobs using pre-prepared INSERT and UPDATE queries. Using Mdba::setparamblob () or Mdb::setparamclob () you can set the value of the LOB field for the pre-prepared query. Two functions are expected to pass a LOB object, and it can be created using Mdb::createlob (). $binary _lob = Array (Type = inputfile, FileName = =/myfile.gif); $blob = $mdb->createlob ($binary _lob); $character _lob = Array (Type = = data, data = would be a very long string container the CLOB data ); $clob = $mdb->createlob ($character _lob); As you can see, Mdb::createlob () is passed an array of relationships. The value of the Type key may be one of the following: data, Inputfile, or outputfile. The first two are used when you want to write the LOB to the database. If you have a lob stored in a variable, you should read the LOB directly from the file when you need to use Inputfile. Finally, Outpufile should be used when you want to read the LOB from the database. Depending on whether you use data or INP
http://www.bkjia.com/PHPjc/531976.html www.bkjia.com true http://www.bkjia.com/PHPjc/531976.html techarticle Write Once-run anywhere write-run anywhere this is a marketing slogan for Java, but it is also one of the key features of PHP. Many business models rely on OS-independent ...
