Co z tym Oracle?

Wybierz w PHP swoje API do bazy:

PHP offers several application-programming interfaces (APIs) for connecting to Oracle—namely, the Oracle, OCI8, and in PHP 5.1, the PDO, extensions. As you will see shortly, PHP offers great functionality but awfully inconsistent naming conventions. Here is some guidance about which extension to deploy:

• Strangely enough, the "Oracle" extension is designed for Oracle7 and should be avoided at all costs. It is obsolete and lacks much functionality such as Large Object (LOB) support.
• PHP Data Objects (PDO) is the new portable database API in the PHP 5.1 release. However, it is still immature.
• On Windows, you can choose to query Oracle via the Open Database Connectivity (ODBC) extension. ODBC has some merits, as it provides built-in connection pooling. But the limited ODBC API means that handling of LOBs and IN OUT parameters in stored procedures can be problematic.
• The OCI8 extension provides the greatest functionality, as it maps very closely to the Oracle Call Interface (OCI). The "8" in OCI8 is misleading; the API can be used with Oracle8/8i, Oracle9i, and Oracle 10g. For best performance, I recommend this API.

Wybierz swoją bibliotekę klas

• Before you start coding your application, you will find it useful to create a set of PHP functions to encapsulate the low-level functionality of the OCI8 extension. You can choose to either roll your own or use one of the popular open source libraries. The two most popular are PEAR DB and ADOdb. (I am the lead developer of the latter.)

  As an example, consider the following code to update a table consisting of three fields: a, b, and c.

  $conn = ocilogon('scott','tiger');
  
  $stmt = OCIParse("insert into abc (a,b,c) values (?,?,?)");
  OCIBindByName($stmt, ":a", $a, 32);
  OCIBindByName($stmt, ":b", $b, 32);
  OCIBindByName($stmt, ":c", $c, 32);
  for ($i=0; $i $a = $i;
   $b = "b".rand();
   $c = "c".rand();
   ociexecute($stmt,OCI_DEFAULT);
  }
  ocicommit($conn);
  

  Contrast this code with the simpler PEAR DB version:

  include('DB.php');
  $DB = &DB::Connect('oci8://scott:tiger@/');
  
  $DB->autoCommit(false);
  $stmt = $DB->prepare("insert into abc (a,b,c) values (?,?,?)");
  for ($i=0; $i $DB->execute($stmt,array($i,"b".rand(),"c".rand()));
  }
  $DB->commit();
  

  Or the really cool ADOdb version:

  include('/path/to/adodb/adodb.inc.php');
  $DB = NewADOConnection('oci8://scott:tiger@/');
  
  $DB->BeginTrans();
  $stmt = $DB->Prepare("insert into abc (a,b,c) values (:0,:1,:2)");
  for ($i=0; $i $DB->_Execute($stmt,array($i,"b".rand(),"c".rand()));
  } 
  $DB->CommitTrans();
  

  You can see that the ADOdb libraries hide nitty-gritty details such as OCIBindByName from you. The libraries also have debugging modes that allow you to log and output the generated SQL for easy problem diagnosis

Pamiętaj o optymalizacji:

• "Although this is not an Oracle-specific optimization, you should also install a PHP accelerator cache such as Zend Accelerator, eAccelerator, or APC to speed up the compilation and loading of PHP code libraries. "

Korzystaj z doświadczeń innych:

• One of the big strengths of PHP over many other tools aimed at solving the Web problem is that other tools tend to associate such very specific targeted problem solving with the need to control how users approach the problem structurally. PHP doesn't impose any such structure, choosing instead to focus on making each individual functionality aspect of the problem as easy as possible to use. For example, PHP provides very targeted functions for communicating with a back-end database. These are specific to each database and do not sacrifice any performance to gain uniformity or consistency with other back-end databases. There is also no set way to structure a PHP application in terms of file layout and what goes where.

• The fact that PHP doesn't impose structure doesn't mean that you shouldn't build your PHP applications in an organized and structured way. Here is one approach I like to show people who ask me how I would go about structuring a large PHP application.

   +--------------------------------+
  |     HTML TEMPLATES             |
  |     $DOC_ROOT/*.php            |
  +--------------------------------+
  |     TEMPLATE HELPERS           |
  |     $DOC_ROOT/*.inc            |
  +--------------------------------+
  |     BUSINESS LOGIC             |
  |     /usr/local/php/*.inc       |
  +--------------------------------+
  |     C/C++ CORE CODE            |
  |     /usr/local/lib/php/*.so    |
  +--------------------------------+

• This four-layer approach addresses a couple of issues. First, it separates the content along the lines of responsibility in a typical project. The Web front-end developers work from the top, and the back-end engineers work from the bottom. They overlap a bit in the template helpers layer. It also separates anything that contains HTML, by putting those files into the document_root and anything that doesn't contain HTML outside the document_root.

• The top template layer typically contains very little PHP—just simple function calls and the odd include. Perhaps a loop. These files are usually edited with an HTML authoring tool. The second layer, the template helpers, is where the interface between the business logic and the layout is defined. This layer might have convenience functions such as start_table(), show_user_record(), and any other reusable component that makes template authors' lives easier.

• The business-logic layer does not contain any HTML at all. This is where such things as SQL queries and any other PHP user-space business logic is implemented. You might expect to see a function such as get_user_record() implemented in this layer. This function would take an ID, perform the appropriate SQL query, and then return an associative array with the result. A function in the layer above then takes this array and wraps some HTML around it to make it look nice.

• The final C/C++ layer is where you put any custom back-end code required for a project. Many people will not have anything for this layer, but if you have a proprietary C or C++ library, you can write a PHP extension to interface to that here. Sometimes this layer is also used when a business-logic function written in user-space PHP turns out to be too slow.

Tricky

• 1. When you are looking for information on a specific PHP function, go to http://php.net/ . For example: http://php.net/join. That takes you directly to the right place in the online manual on a server geographically near you.

• 2. Try this: pear install apc . The pear command is a useful installer that can even be used to install PHP extensions written in C. In this case, it would install the APC opcode cache extension.

  3. Use an opcode cache to improve performance. See #2.

  4. There is nothing wrong with mixing OOP and procedural code in PHP. Use objects when they make sense, and go procedural for the rest.

  5. Extending PHP with your own custom C or C++ extensions is easier than you might think. See README.EXT_SKEL in the PHP source distribution.

  6. The echo << syntax is useful for outputting blocks of text with full $variable substitution, without needing to escape anything. EOB;

  7. PATH_INFO is good! Use it to clean up ugly URLs.

  8. Use a profiler, pear install apd.

  9. Database abstraction is mostly a myth. There is nothing wrong with direct database calls' making use of all the tricks and cheats your chosen database has to offer, to tweak as much performance as possible out of it.