5.2 选择API
本节介绍根据各种类型的应用程序选择A P I的方法，比较C、DBI 和PHP API 的能力，并给出它们相对的优点和缺点，并指出什么时候应选择哪一个。
首先应该指出，笔者不认为任一种语言优于其他语言。尽管笔者的确有自己的喜好，但还是统统使用它们。您也会有自己的喜好，像我的评论家一样。一个评论家会感觉应该强调C 对MySQL编程的重要性，应将这种重要性上升到更重要的程度，而另一个评论家会认为C
编程相当困难，应放?褂盟?∧?Φ比ê獗窘谥刑致鄣恼庑┮蛩兀?贸鲎约旱慕崧邸Ｔ诙蕴囟ㄈ挝裱≡衲母鯝PI 时，要考虑以下问题：
■ 预期的执行环境。期望使用应用程序的上下文环境。
■ 性能。当在API 语言中编写时，如何使应用程序高效地执行。
■ 开发的容易性。如何便于API 和它的语言编写应用程序。
■ 可移植性。除MySQL以外，应用程序是否还将用于其他数据库系统。
下面进一步分析每个问题。要注意这些因素的相互影响。例如，您想要一个运行良好的应用程序，但使用一个可快速开发该应用程序的语言也同等重要，即使该应用程序不能非常有效地运行也同样。
5.2.1执行环境
当编写应用程序时，通常应考虑使用哪种环境。例如，该应用程序可能是从外壳程序中调用的报告生成器程序，或一个应付账目概要程序，在每月的月底作为cron job 进行运行。从外壳程序或cron 程序中运行的命令通常依赖它们自己，而且很少需要运行环境。另外，可以编写一个应用程序来试图由Web 服务器调用。这样的程序期望能从它的运行环境中抽出非常特殊类型的信息：客户正在使用什么浏览器？在邮件清单订阅请求格式中输入什么参数？客户提供正确的口令访问我们个人信息了吗？每种API 语言都以它在这些不同的环境中适于编写应用程序而变化：
■C 是通用目标的语言，从理论上讲任何任务都可使用它。在实际中， C 倾向于用于更频繁的独立程序而不是对Web 的编程。其原因可能是在C 中不像在Perl 或在PHP 中那样容易地实现文本处理和内存管理，并且这些处理和管理在Web 应用程序中大量地使用。
■ Perl，像C 一样，适合于编写独立的程序。然而，对于Web 站点的开发，Perl 也是非常有用的，例如通过使用CGI.pm 模块。这使Perl 成为编写连接MySQL和Web 的应用程序的便利的语言。这样的应用程序可以经CGI.pm 模块与Web 接口，并可以使用DBI 与MySQL相互作用。
■ PHP 是设计用来编写Web 应用程序的语言，所以这个环境显然是最适合的。而且，数据库访问是PHP 最大的优势之一，所以它是实现与MySQL相关的任务的Web 应用程序最自然的选择。也可以将PHP 作为一个独立的解释程序（例如，从外壳程序中运行脚本），但不能非常频繁地使用它。
根据以上这些需要考虑的问题，对于独立的应用程序， C 和Perl 是最佳语言。对于We b应用程序， Perl 和PHP 是最合适的。如果需要编写这两种类型的应用程序，但又不会使用这些语言的任何一种，并想用尽可能少的精力来学习，则Perl 可能是您最佳的选择。
5.2.2 性能
我们通常喜欢应用程序尽可能快地运行。然而，实际上性能的重要性取决于所使用的程序的频率。对于一个月运行一次晚上定时工作的程序，性能可能不是非常重要的。而对于在Web 站点上一秒钟运行若干次的程序，则每当排除一点无效性都会带来巨大的不同。后一种
情况下，在站点的有效性和请求中，性能发挥着重要的作用。一个缓慢的站点是令用户苦恼的，无论站点的内容如何，如果您依靠站点作为一项收入来源，则性能的降低直接影响收入。如果不能一次为多个连接提供服务，访问者只会产生厌烦情绪而去其他的站点。
性能评价是一个复杂的问题。当编写特定的API 时，应用程序完成得好坏的最好指标是在这个API 环境下编写并进行测试。而且最好的比较测试是在不同的API 环境下多次运行该应用程序，来比较每个版本。当然，那不是一般的工作。一般来说，您只想获取编写的应用
程序。一旦它工作了，如果它需要运行得更快，您就可以考虑优化它，使用更少的内存，或有某些需要用其他方法提高的方面。但是，至少有如下两个因素会影响性能：
■ 编译的程序比解释的程序运行得更快。
■ 对于在Web 上下文环境中使用的解释语言，在解释程序作为We b服务器自身的一部分而不是单独的过程模块被调用时，性能更好。
1. 相对于解释语言的编译语言
编译的应用程序比用脚本语言编写的程序的同样版本效率更高、使用的内存更少，并且执行得更快，这是基本规律。这是由于执行脚本的语言的解释程序的开销问题。因为C 是编译的，而Perl 和PHP 是解释的，所以C 程序通常比Perl 或PHP 脚本运行得更快一些。对于大量使用的程序，通常用C 是最好的选择。在MySQL分发包中包括的mysql命令行客户机程序就是最好的样例。
当然，有一些因素能使这种明显的差别减小。对于一项任务，可用C 编写出更快的程序，但也很有可能编写出低效率的C 程序。用编译语言编写的程序并不自动地保证更好的性能。所以需要不断地考虑所做的事情。此外，如果一个脚本化的应用程序需花费大部分时间来执行连接到解释程序引擎的MySQL客户机库例程的代码，则编译程序和解释程序之间的差别将有所减少。
2. 相对于语言解释程序模块版本的独立程序
对于基于Web 的应用程序，脚本语言解释程序通常以两种形式之一来使用，至少对Apache 是这样，当编写Web 应用程序时，Apache 是我们将使用的Web 服务器：
■ 可以安排Apache 去调用这个解释程序作为单独的过程。当Apache 需要运行Perl 或PHP 脚本时，它启动相应的程序，并告知它来执行该脚本。在这种情况下， Apache 使用该解释程序作为CGI 程序，也就是说，它使用公共网关接口（ Common Gateway Inter face，CGI）协议与它们通信。
■ 解释程序可用作直接连接到Apache 二进制程序和作为其过程自身的一部分运行的模块。在Apache 条件下， Perl 和PHP 解释程序获得mod_perl 和mod_php3 模块的形式。
Perl 和PHP 的提倡者们极力宣扬解释程序有速度优势，但所有的人都同意之所以喜欢解释程序是因为其运行的形式比语言本身有更大的诱惑力。在这两者中，解释程序作为模块运行比作为独立的CGI 应用程序运行更快。
对于独立的应用程序，每当运行一个脚本时都必须启动该解释程序，所以将导致重大的创建过程的开销。当在已经运行Apache 过程的内部作为模块使用时，解释程序可以立即从Web 页面中访问。通过减少开销显著地提高了性能，并直接转换为快速处理获取的请求并发
送它们的能力的增加。
独立解释程序启动的性能比模块解释程序的性能至少差一个数量级。当考虑Web 页面服务包括少量处理的快速事务处理而不是具有许多处理时，解释程序启动的开销特别重要。如果花费许多时间只是为了启动而不是用于实际执行该脚本，则大部分资源一直处于等待状态。一天中的大部分时间可能花费在准备工作上， 4 点到达，然后5 点回家。
您可能想知道，为什么解释程序的模块版本由于必须一直启动Apache 而能节省时间呢？。这个原因是，当Apache 启动时，它立即产生一些子过程，用于处理收到的请求。当包括脚本执行的请求到达时，已经有Apache 进程在准备等待去处理它。同样， Apache 的每个实例可服务于多个请求，所以该进程启动的开销只导致每组请求一次，而不是每个请求一次。
当Perl 和PHP 以模块形式安装时（像mod_perl 和m o d _ p h p 3），哪一个完成得更好一些？那就是争论的主题，以下是适用于一般性的指南：
■ Perl 将脚本转换为内部可编译的形式；而PHP 却不这样。因此，一旦该脚本通过语法分析，则Perl 可更快地执行它，特别是对于具有大量迭代的循环。
■ mod_perl 可以运行脚本高速缓存来提高重复执行的脚本的性能。如果脚本在高速缓存中，则Perl 可更快地开始执行脚本，因为它不需要再一次分析。否则， PHP 开始执行的该脚本的速度更快。
■ mod_perl 比PHP 有更大的内存覆盖区；利用mod_perl 连接的Apache 进程比利用mod_php3 的更大。PHP 被假定必须在另一个进程的内部协同存在，并且在那个进程内部可以多次激活或撤消。Perl 被设计成从命令行作为独立程序运行，而不是作为被嵌入在Web 服务器进程中的一个语言进行运行。这可能使它付出较大的内存覆盖区；
Perl是模块，因此它不运行在自身环境中。脚本的高速缓存和该脚本使用的附加Perl模块是付出较大的内存覆盖区的另外的因素。在这两种情况下，有更多的代码使用内存，并将运行的Apache 进程保留在内存中。
在脚本运行速度方面，Perl 无论有什么可超过PHP 的优势，都被PHP 4 除掉了。PHP 4 在它的能力和接口方面类似于PHP 3，但它合并了Zend，Zend 是一种更高性能的解释程序的引擎。
无论如何，所有的这些因素只导致Perl 和PHP 的模块版本之间性能比不同。无论您选择哪种语言，最重要的是尽可能地避免独立的解释程序。
解释程序的独立版本的确有一个优点超过它的模块版本，即可以安排它在不同的用户ID下运行。模块版本始终运行在与Web 服务器相同的用户ID 下，出于安全原因，该用户是一个典型的具有很少权限的账号。对于需要特殊权限的脚本来说不能很好地运行（例如，如果您需要能读写受保护的文件）。如果愿意，可以将模块方法和独立方法结合起来：缺省情况下使用模块版本，而在具有特定用户的权限的脚本的情况下使用独立版本。
降低mod_perl 的内存需求
有些技术允许您只能对mod_perl 使用某些的Apache 进程。这样，只对运行Perl 脚本的那些进程产生额外的内存开销。Apache Web 站点的mod_perl 部分有可选择的各种策略的讨论（有关的详细信息，请参阅h t t p : / / per l . a p a c h e . o rg / g ui d e /）。综上考虑，也就是说，选择Perl 还是PHP，您应该试着从Apache 模块中而不是通过调用一个单独的解释程序过程来使用它。只对不能由模块处理的那些情况使用独立的解释程序，例如需要特殊权限的脚本。对于这些实例，可以通过使用Apache 的suEXEC 机制在给定的用户ID 下启动解释程序来处理脚本。
5.2.3 开发时间
刚才描述的这些因素影响应用程序的性能，但不能只考虑运行效率。时间及编程的简易性也是重要的，所以为MySQL编程选择API 时要考虑的另一个因素是如何很快地开发出自己的应用程序。如果开发同样程序，用Perl脚本只需用C 语言一半的时间，那您可能宁愿使用Perl DBI API，而非C API，即使开发出的应用程序运行速度不是非常快也如此。考虑程序的运行时间比考虑编写程序时花的时间更少一些通常是合理的，特别是对不经常运行的应用程序更是如此。您的一小时比机器的一小时要值钱得多！
一般来说，脚本语言编写程序更快，特别是得到应用程序的原型更快，这是由于以下两个原因：
第一，脚本语言提供更高级别的结构。这允许您在抽象的更高级别上进行思考，以便集中考虑要做些什么，而不是考虑如何做。例如， Perl 的关联数组（散列）对于维护具有键/值系（如学生ID /学生姓名对）的数据节省了大量时间。C 没有这样的构造。如果想在C 中实现这样的事情，则可能需要编写代码来处理许多低级的细节，其中包括内存管理和串操纵的问题，并且需要调试它，这也要花时间。
第二，脚本语言的开发周期的步骤较少。用C 开发应用程序时，要经历通常的编辑—编译—测试的循环周期。每次修改程序时，在测试之前都必须重新编译它。而用Perl 和PHP，由于每次修改后不用编译就可以立即运行脚本，因此，开发周期可简化为编辑—测试。另一方面，编译程序对程序在严格的类型检查形式方面有更多的约束条件。编译程序施加的更多约束条件有助于避免在松散语言(如Perl 和PHP )中不易捕获的错误。在C 中，如果您错误地拼写了变量的名称，则编译程序将警告您。PHP 不这样，Perl 也不这样，除非向它询问。当应用程序变得更大且更难于维护时，这些更严格的约束条件可能特别有用。
一般来说，在编译和解释语言之间权衡的是开发时间与性能的折衷：是想要使用编译语言开发程序，以便在运行时可以更快，但花费更多的时间来编写它？还是想要用脚本语言编写程序，以便在缩短编程时间，但要损失一些运行速度？
将两种方法合并起来也是可能的。编写一个脚本作为“第一个草案”来快速地开发出一个应用程序原型以测试其逻辑性，确定算法的可用性。如果这个程序有用，并且被频繁使用，则性能成为关心的焦点，这时可作为编译的应用程序重新对它编写代码。这样做给您带来两种方法的优点：快速得到应用程序的初始开发原型，同时得到最终产品的最佳性能。从某种严格的意义来说， Perl DBI 和PHP API 并没有给您在C 客户机库中没有的能力。这是因为这两种API 通过MySQLC 库连接到Perl 和PHP 解释程序来获取对MySQL的访问。然而，对于嵌入MySQL的环境，C 与Perl 或PHP 有很大的不同。应考虑在与MySQL服务器相互作用时要做的事情并提问每个API 语言如何帮助您完成这些事情。下面有一些样例：
■ 内存管理。在C中，您发现自己对任何任务，包括动态分配数据结构都使用malloc() 和free() 来工作。Perl 和PHP 可为您处理这些任务。例如，数组的大小自动地增加，并且可以使用动态长度的字符串而不用考虑内存管理。
■ 文本处理。在这点Perl 具有最大的开发能力，而PHP 位于第二。比较起来，C 是非常初级的。当然，可以用C编写自己的库，将内存管理和文本处理这样一些任务封装成更容易工作的函数。但是，然后还必须调试它们，并且您也想使自己的算法效率更高。在这两个方面，基本上可以断定，由于它们已经具有了通过许多双眼睛检查过的好处，对这些事情Perl 和PHP中的算法一般是易于调试并且有合理的效率。通过利用其他人的工作可以节省您的时间（另一方面，如果解释程序偶尔有一个错误，您可能必须携带它，直到这个问题纠正为止。而用C 编写时，可以更细地控制程序性能）。
这些语言的不同还在于它们的“安全性”。C API 提供对服务器最低级别的接口，而且强制的原则最少。从这种意义上说，它提供最低级的安全性网络。如果您超出正常顺序执行API 函数，则可能获得一个“超出同步”的错误，或使程序崩溃。Perl 和PHP 都提供了很好的保护。如果您没有以适当的顺序进行，则脚本失败，但是解释程序并不崩溃。在C 程序中，出现崩溃错误的另一个非常可能的来源是动态分配内存和与它们相关的指针的使用。Perl 和PHP 为您处理内存管理，所以您的脚本很少可能因为内存管理的错误而瘫痪。
开发时间受语言可用的外部支持的影响。C 可用的外部支持是将MySQLC API 函数封装为更容易使用的实例的包装库的形式。这些库对于C 和C++ 都可用。Perl 无疑具有最大数量的附加软件，都是Perl 模块的形式（与在Apache 模块中具有的概念类似）。甚至有一个基础结构被设计来容易地定位并获取这些模块（即综合Perl 归档网络Comprehensive Perl Archive Network, CPA N）。使用Perl 模块，不用编写代码就可以获取对所有类型的函数的访问。想要编写从数据库中生成报告的脚本，然后作为一个附件发送给某人吗？只要获取MIME 模块中的一个，就立即具有附件生成的能力。
PHP 没有同样程度的外部支持（这并不令人惊奇，因为它是较新的语言）。也许所知道的最佳的附加软件是PHP基本库（ PHP Base Library，PHP LIB）。根据名称和口令机制的一些排序，假设您正在编写需要限定只有经授权的用户才可以对某个Web 页面访问的Web 应用程序。可以用任意语言编写对它的支持程序，但是如果使用PHP L I B，则不必花费时间重新做这件事情。PHP L I B提供确认并且允许通过会话跟踪经授权的用户（从作为单个逻辑访问部分的给定客户机中连续页面的命中）。还可以分配给用户许可权，这允许您进行像定义具有更多权限的管理用户的工作。
5.2.4 可移植性
可移植性的问题与为访问MySQL引擎所编写的程序怎样才能容易地修改为使用不同引擎的程序有关。您可能不担心这个事情。然而，除非可以预知未来，否则，说“除了MySQL以外，我永远都不会将这个程序用在任何其他的数据库上”可能有些冒险：假设您找到另一
份工作，并想使用自己的旧程序，但您的新老板使用不同的数据库系统呢？如果可移植性是需要优先考虑的事情，则应该考虑在API 之间的区别：
■ DBI API的可移植性最好，因为它独立于数据库是DBI 设计的一个明确目标。
■ PHP 的可移植性稍差，因为它不提供对DBI 提供的各种数据库引擎的同样类型的统一接口。对每个支持数据库的PHP 函数的调用类似于在相应的基础C API 中的那些。稍有一些不同，但很少，需要更改您调用的数据库相关函数的名称。还有可能要修改一点应用程序的逻辑，因为不同数据库的借口并不都是以同样的方式工作的。
■ C API 提供的数据库之间的可移植性最差。因为它生来就是为MySQL设计的。当需要在同一个应用程序中访问多个数据库系统时，独立于数据库的可移植性特别重要。这可能包括像将数据从一个RDBMS 移动到另一个RDBMS 中的简单任务，或更复杂的任务，如基于从许多数据库系统中得到的信息生成报告。
DBI 和PHP 都提供对访问多个数据库引擎的支持，所以对不同的数据库，甚至在不同的主机上，都可以很容易地同时连接到服务器上。然而， DBI 和PHP 在对于从多个异构数据库系统中检索和处理数据的任务的适宜性方面有所不同。而DBI 更好些，因为无论使用哪种数据库，它都使用一组单独的访问调用。假设想在MySQL、mSQL 和Postgres 数据库之间传送数据。使用DBI，则使用这三种数据库的惟一不同之处在于用于连接到每个服务器的DBI -> connect( )调用。而用PHP时，可能需要有更复杂的脚本，该脚本将含有三组读取调用和三组写入调用。
多数据库应用程序的一个极好的例子是MySQL分发包中的crash-me 脚本，它可测试许多不同的数据库服务器的能力。该脚本是用DBI编写的，对于这样的应用程序，这种选择是很明显的，因为您可以同样的方式访问所有的数据库。
