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 可更快地执行它，特别是对于具