通过缓存数据库结果提高PHP性能(4)

　构建客户端
　　现在，您已经针对 ORDERS 和 ORDER_ITEMS
表创建了注册，下面我们将了解一下访问这些表中存储的订单及其订单项的客户端应用程序如何使用更改通知。为此，您可以构建一个 PHP
应用程序，它将缓存针对以上表的查询结果，并采取相应的操作来响应有关对这些表所做更改的通知（从数据库服务器中收到这些通知）。一个简单的方法是使用
PEAR::Cache_Lite 程序包，它为您提供了一个可靠的机制来使缓存数据保持最新状态。尤其是，您可以使用 Cache_Lite_Function
类（PEAR::Cache_Lite 程序包的一部分），通过该类您可以缓存函数调用。
　　例如，您可以创建一个函数来执行下列任务：建立数据库连接、针对该数据库执行 select
语句、获取检索结果并最终以数组形式返回结果。然后，您可以通过 Cache_Lite_Function 实例的 call
方法缓存由该函数返回的结果数组，以便可以从本地缓存而不是从后端数据库读取这些数组，这样可以显著提高应用程序的性能。然后，在收到缓存数据更改的通知时，您将使用
Cache_Lite_Function 实例的 drop 方法删除缓存中的过期数据。
　　回过头来看看本文的示例，您可能要创建两个函数，用于应用程序与数据库交互：第一个函数将查询 ORDERS 表并返回具有指定 ID
的订单，而另一个函数将查询 ORDER_ITEMS 表并返回该订单的订单项。“清单 4”显示了包含 getOrderFields 函数（该函数接受订单 ID
并返回一个包含所检索到订单的某些字段的关联数组）的 getOrderFields.php 脚本。
　　清单 4.
获取指定订单的字段

＜?php 
//File:getOrderFields.php 
require_once 'connect.php'; 
function getOrderFields($order_no) { 
if (!$rsConnection = GetConnection()){ 
return false; 
   } 
$strSQL = "SELECT TO_CHAR(ORDER_DATE) ORDER_DATE, CUSTOMER_ID,  
ORDER_TOTAL FROM ORDERS WHERE order_id =:order_no"; 
$rsStatement = oci_parse($rsConnection,$strSQL); 
oci_bind_by_name($rsStatement, ":order_no", $order_no, 12); 
if (!oci_execute($rsStatement)) { 
$err = oci_error(); 
print $err['message']; 
trigger_error('Query failed:' . $err['message']); 
     
将表添加到现有注册 
　　前一部分介绍了如何使用更改通知服务使数据库在注册对象（在以上示例中为 ORDERS 
表）发生更改时发出通知。但从性能角度而言，客户端应用程序可能更希望缓存 ORDER_ITEMS 表而非 ORDERS 
表本身的查询结果集，这是因为它在每次访问订单时，不得不从 ORDERS 表中只检索一行，但同时必须从 ORDER_ITEMS 
表中检索多个行。在实际情况中，订单可能包含数十个甚至数百个订单项。
　　由于您已经对 ORDERS 表注册了查询，因此不必再创建一个注册来注册对 
ORDER_ITEMS 表的查询了。相反，您可以使用现有注册。为此，您首先需要检索现有注册的 ID。可以执行以下查询来完成此工作： 
SELECT regid, table_name FROM user_change_notification_regs;
　　结果可能如下所示： 
REGID TABLE_NAME 
----- -------------- 
241 OE.ORDERS 
　　获取注册 ID 后，可以使用 DBMS_CHANGE_NOTIFICATION.ENABLE_REG 
函数将一个新对象添加到该注册，如下所示：
DECLARE 
ord_id NUMBER; 
BEGIN 
DBMS_CHANGE_NOTIFICATION.ENABLE_REG(241); 
SELECT order_id INTO ord_id FROM order_items WHERE ROWNUM ＜ 2; 
DBMS_CHANGE_NOTIFICATION.REG_END; 
END; 
/ 
　　完成了！从现在开始，数据库将生成一个通知来响应对 ORDERS 和 ORDER_ITEMS 所做的任何更改，并调用 
orders_nf_callback 过程来处理通知。因此，下一步就是编辑 orders_nf_callback，以便它可以处理因对 ORDER_ITEMS 
表执行 DML 操作而生成的通知。但在重新创建 orders_nf_callback 过程之前，您需要创建以下将在更新过程中引用的表类型： 
CREATE TYPE rdesc_tab AS TABLE OF SYS.CHNF$_RDESC;
　　然后，返回清单 
2，在以下代码行之后：
IF (tblname = 'OE.ORDERS') THEN 
FOR j IN 1..numrows LOOP 
row_id := ntfnds.table_desc_array(i).row_desc_array(j).row_id; 
SELECT order_id INTO ord_id FROM orders WHERE rowid = row_id; 
sendNotification(url, tblname, ord_id);  
END LOOP; 
END IF; 
　　插入以下代码：
IF (tblname = 'OE.ORDER_ITEMS') THEN 
     
　　触发器是类似于存储程序的数据库对象，它响应数据库环境下的某个请求。SQL Sever 2005包含3个触发器对象：AFTER，数据定义语言 (DDL)和INSTEAD-OF。
　　AFTER触发器是存储程序，它发生于数据操作语句作用之后，例如删除语句等。DDL是SQL Server 2005的新触发器，允许响应数据库引擎中对象定义水平事件（例如：DROP TABLE语句）。INSTEAD-OF触发器是对象，在数据库引擎中可以取代数据操作语句而执行。例如：将INSTEAD-OF INSERT触发器附加到表，告诉数据库执行此触发器。
　　使用INSTEAD-OF触发器的理由
　　INSTEAD-OF触发器是SQL Sever功能强大的对象，允许开发人员转移数据库引擎完成不同的工作，以满足开发要求。其中的一个例子是在数据库的表中添加INSTEAD-OF触发器，当不需要修改表时，可以对表的内容进行回滚。使用此方法时，必须格外小心，因为任何指定的表修改之前，INSTEAD-OF触发器必须处于激活状态。
　　使用INSTEAD-OF触发器一个更充分理由是视图处理。在视图中添加INSTEAD-OF触发器后，则可创建更新的视图。可更新视图允许完整地提取数据库大纲，因此可以用此方法设计系统，而不需要担心OLTP数据库大纲的问题，并且取代数据修改一组标准视图集。
　　范例
　　为了更好地说明可更新视图概念，我们提供一个示例。在本例中，我们设计一个产品表（记录产品），一个购买表（记录购买）。Listing A包含了创建表的脚本，运行此脚本后则得到示例中所要用到的表。运行Listing B脚本向表中添加数据。
　　现在表中已经有数据了，我可以为这些表创建一些有意义的视图。请查看Listing C。
　　这是个典型的产品水平的视图。它联合了数据库中的两个表，使得数据简单化了。但是，对于数据提取，使用视图则没有什么优势。在视图上附上INSTEAD-OF触发器后，则允许修改表，但是我不需要直接修改表中的数据。我使用Listing D中的代码在vw_ProductPurchases视图上创建一个INSTEAD-OF触发器。
　　请注意此INSTEAD OF触发器的声明。SQL Server创建的默认的触发器为AFTER触发器，因此，必须在触发器定义中指定INSTEAD OF子句。
　　触发器的第一条语句是“check”语句。本例中我使用此语句检测INSERTED表以确保显示ProductID字段，并且保证提供显示其他PurchasePrice 或 ProductPrice字段。
     
              
数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。
 　从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。
笔者在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。
分析问题
许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。系统所做查询优化我们暂不讨论，下面重点说明改善用户查询计划的解决方案。
解决问题
下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。
     
              

虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：

 （T114）