5.2 選擇API
    本節(jié)介紹根據(jù)各種類型的應(yīng)用程序選擇A P I的方法，比較C、DBI 和PHP API 的能力，并給出它們相對(duì)的優(yōu)點(diǎn)和缺點(diǎn)，并指出什么時(shí)候應(yīng)選擇哪一個(gè)。
    首先應(yīng)該指出，筆者不認(rèn)為任一種語言優(yōu)于其他語言。盡管筆者的確有自己的喜好，但還是統(tǒng)統(tǒng)使用它們。您也會(huì)有自己的喜好，像我的評(píng)論家一樣。一個(gè)評(píng)論家會(huì)感覺應(yīng)該強(qiáng)調(diào)C 對(duì)MySQL 編程的重要性，應(yīng)將這種重要性上升到更重要的程度，而另一個(gè)評(píng)論家會(huì)認(rèn)為C
編程相當(dāng)困難，應(yīng)放棄使用它！您應(yīng)當(dāng)權(quán)衡本節(jié)中討論的這些因素，得出自己的結(jié)論。在對(duì)特定任務(wù)選擇哪個(gè)API 時(shí)，要考慮以下問題：
    ■ 預(yù)期的執(zhí)行環(huán)境。期望使用應(yīng)用程序的上下文環(huán)境。
    ■ 性能。當(dāng)在API 語言中編寫時(shí)，如何使應(yīng)用程序高效地執(zhí)行。
    ■ 開發(fā)的容易性。如何便于API 和它的語言編寫應(yīng)用程序。
    ■ 可移植性。除MySQL 以外，應(yīng)用程序是否還將用于其他數(shù)據(jù)庫系統(tǒng)。
    下面進(jìn)一步分析每個(gè)問題。要注意這些因素的相互影響。例如，您想要一個(gè)運(yùn)行良好的應(yīng)用程序，但使用一個(gè)可快速開發(fā)該應(yīng)用程序的語言也同等重要，即使該應(yīng)用程序不能非常有效地運(yùn)行也同樣。
    5.2.1 執(zhí)行環(huán)境
    當(dāng)編寫應(yīng)用程序時(shí)，通常應(yīng)考慮使用哪種環(huán)境。例如，該應(yīng)用程序可能是從外殼程序中調(diào)用的報(bào)告生成器程序，或一個(gè)應(yīng)付賬目概要程序，在每月的月底作為cron job 進(jìn)行運(yùn)行。從外殼程序或cron 程序中運(yùn)行的命令通常依賴它們自己，而且很少需要運(yùn)行環(huán)境。另外，可以編寫一個(gè)應(yīng)用程序來試圖由Web 服務(wù)器調(diào)用。這樣的程序期望能從它的運(yùn)行環(huán)境中抽出非常特殊類型的信息：客戶正在使用什么瀏覽器？在郵件清單訂閱請(qǐng)求格式中輸入什么參數(shù)？客戶提供正確的口令訪問我們個(gè)人信息了嗎？每種API 語言都以它在這些不同的環(huán)境中適于編寫應(yīng)用程序而變化：
    ■C 是通用目標(biāo)的語言，從理論上講任何任務(wù)都可使用它。在實(shí)際中， C 傾向于用于更頻繁的獨(dú)立程序而不是對(duì)Web 的編程。其原因可能是在C 中不像在Perl 或在PHP 中那樣容易地實(shí)現(xiàn)文本處理和內(nèi)存管理，并且這些處理和管理在Web 應(yīng)用程序中大量地使用。
    ■ P e r l，像C 一樣，適合于編寫?yīng)毩⒌某绦?。然而，?duì)于Web 站點(diǎn)的開發(fā)，Perl 也是非常有用的，例如通過使用CGI.pm 模塊。這使Perl 成為編寫連接MySQL 和Web 的應(yīng)用程序的便利的語言。這樣的應(yīng)用程序可以經(jīng)CGI.pm 模塊與Web 接口，并可以使用DBI 與MySQL 相互作用。
    ■ PHP 是設(shè)計(jì)用來編寫Web 應(yīng)用程序的語言，所以這個(gè)環(huán)境顯然是最適合的。而且，數(shù)據(jù)庫訪問是PHP 最大的優(yōu)勢(shì)之一，所以它是實(shí)現(xiàn)與MySQL 相關(guān)的任務(wù)的Web 應(yīng)用程序最自然的選擇。也可以將PHP 作為一個(gè)獨(dú)立的解釋程序（例如，從外殼程序中運(yùn)行腳本），但不能非常頻繁地使用它。
    根據(jù)以上這些需要考慮的問題，對(duì)于獨(dú)立的應(yīng)用程序， C 和Perl 是最佳語言。對(duì)于We b應(yīng)用程序， Perl 和PHP 是最合適的。如果需要編寫這兩種類型的應(yīng)用程序，但又不會(huì)使用這些語言的任何一種，并想用盡可能少的精力來學(xué)習(xí)，則Perl 可能是您最佳的選擇。
    5.2.2 性能
    我們通常喜歡應(yīng)用程序盡可能快地運(yùn)行。然而，實(shí)際上性能的重要性取決于所使用的程序的頻率。對(duì)于一個(gè)月運(yùn)行一次晚上定時(shí)工作的程序，性能可能不是非常重要的。而對(duì)于在Web 站點(diǎn)上一秒鐘運(yùn)行若干次的程序，則每當(dāng)排除一點(diǎn)無效性都會(huì)帶來巨大的不同。后一種
情況下，在站點(diǎn)的有效性和請(qǐng)求中，性能發(fā)揮著重要的作用。一個(gè)緩慢的站點(diǎn)是令用戶苦惱的，無論站點(diǎn)的內(nèi)容如何，如果您依靠站點(diǎn)作為一項(xiàng)收入來源，則性能的降低直接影響收入。如果不能一次為多個(gè)連接提供服務(wù)，訪問者只會(huì)產(chǎn)生厭煩情緒而去其他的站點(diǎn)。
    性能評(píng)價(jià)是一個(gè)復(fù)雜的問題。當(dāng)編寫特定的API 時(shí)，應(yīng)用程序完成得好壞的最好指標(biāo)是在這個(gè)API 環(huán)境下編寫并進(jìn)行測(cè)試。而且最好的比較測(cè)試是在不同的API 環(huán)境下多次運(yùn)行該應(yīng)用程序，來比較每個(gè)版本。當(dāng)然，那不是一般的工作。一般來說，您只想獲取編寫的應(yīng)用
程序。一旦它工作了，如果它需要運(yùn)行得更快，您就可以考慮優(yōu)化它，使用更少的內(nèi)存，或有某些需要用其他方法提高的方面。但是，至少有如下兩個(gè)因素會(huì)影響性能：
    ■ 編譯的程序比解釋的程序運(yùn)行得更快。
    ■ 對(duì)于在Web 上下文環(huán)境中使用的解釋語言，在解釋程序作為We b服務(wù)器自身的一部分而不是單獨(dú)的過程模塊被調(diào)用時(shí)，性能更好。
    1. 相對(duì)于解釋語言的編譯語言
    編譯的應(yīng)用程序比用腳本語言編寫的程序的同樣版本效率更高、使用的內(nèi)存更少，并且執(zhí)行得更快，這是基本規(guī)律。這是由于執(zhí)行腳本的語言的解釋程序的開銷問題。因?yàn)镃 是編譯的，而Perl 和PHP 是解釋的，所以C 程序通常比Perl 或PHP 腳本運(yùn)行得更快一些。對(duì)于大量使用的程序，通常用C 是最好的選擇。在MySQL 分發(fā)包中包括的mysql 命令行客戶機(jī)程序就是最好的樣例。
    當(dāng)然，有一些因素能使這種明顯的差別減小。對(duì)于一項(xiàng)任務(wù)，可用C 編寫出更快的程序，但也很有可能編寫出低效率的C 程序。用編譯語言編寫的程序并不自動(dòng)地保證更好的性能。所以需要不斷地考慮所做的事情。此外，如果一個(gè)腳本化的應(yīng)用程序需花費(fèi)大部分時(shí)間來執(zhí)行連接到解釋程序引擎的MySQL 客戶機(jī)庫例程的代碼，則編譯程序和解釋程序之間的差別將有所減少。
    2. 相對(duì)于語言解釋程序模塊版本的獨(dú)立程序
    對(duì)于基于Web 的應(yīng)用程序，腳本語言解釋程序通常以兩種形式之一來使用，至少對(duì)Apache 是這樣，當(dāng)編寫Web 應(yīng)用程序時(shí)，Apache 是我們將使用的Web 服務(wù)器：
    ■ 可以安排Apache 去調(diào)用這個(gè)解釋程序作為單獨(dú)的過程。當(dāng)Apache 需要運(yùn)行Perl 或PHP 腳本時(shí)，它啟動(dòng)相應(yīng)的程序，并告知它來執(zhí)行該腳本。在這種情況下， Apache 使用該解釋程序作為CGI 程序，也就是說，它使用公共網(wǎng)關(guān)接口（ Common Gateway Inter face，CGI）協(xié)議與它們通信。
    ■ 解釋程序可用作直接連接到Apache 二進(jìn)制程序和作為其過程自身的一部分運(yùn)行的模塊。在Apache 條件下， Perl 和PHP 解釋程序獲得mod_perl 和mod_php3 模塊的形式。
    Perl 和PHP 的提倡者們極力宣揚(yáng)解釋程序有速度優(yōu)勢(shì)，但所有的人都同意之所以喜歡解釋程序是因?yàn)槠溥\(yùn)行的形式比語言本身有更大的誘惑力。在這兩者中，解釋程序作為模塊運(yùn)行比作為獨(dú)立的CGI 應(yīng)用程序運(yùn)行更快。
    對(duì)于獨(dú)立的應(yīng)用程序，每當(dāng)運(yùn)行一個(gè)腳本時(shí)都必須啟動(dòng)該解釋程序，所以將導(dǎo)致重大的創(chuàng)建過程的開銷。當(dāng)在已經(jīng)運(yùn)行Apache 過程的內(nèi)部作為模塊使用時(shí)，解釋程序可以立即從Web 頁面中訪問。通過減少開銷顯著地提高了性能，并直接轉(zhuǎn)換為快速處理獲取的請(qǐng)求并發(fā)
送它們的能力的增加。
    獨(dú)立解釋程序啟動(dòng)的性能比模塊解釋程序的性能至少差一個(gè)數(shù)量級(jí)。當(dāng)考慮Web 頁面服務(wù)包括少量處理的快速事務(wù)處理而不是具有許多處理時(shí)，解釋程序啟動(dòng)的開銷特別重要。如果花費(fèi)許多時(shí)間只是為了啟動(dòng)而不是用于實(shí)際執(zhí)行該腳本，則大部分資源一直處于等待狀態(tài)。一天中的大部分時(shí)間可能花費(fèi)在準(zhǔn)備工作上， 4 點(diǎn)到達(dá)，然后5 點(diǎn)回家。
    您可能想知道，為什么解釋程序的模塊版本由于必須一直啟動(dòng)Apache 而能節(jié)省時(shí)間呢？。這個(gè)原因是，當(dāng)Apache 啟動(dòng)時(shí)，它立即產(chǎn)生一些子過程，用于處理收到的請(qǐng)求。當(dāng)包括腳本執(zhí)行的請(qǐng)求到達(dá)時(shí)，已經(jīng)有Apache 進(jìn)程在準(zhǔn)備等待去處理它。同樣， Apache 的每個(gè)實(shí)例可服務(wù)于多個(gè)請(qǐng)求，所以該進(jìn)程啟動(dòng)的開銷只導(dǎo)致每組請(qǐng)求一次，而不是每個(gè)請(qǐng)求一次。
    當(dāng)Perl 和PHP 以模塊形式安裝時(shí)（像mod_perl 和m o d _ p h p 3），哪一個(gè)完成得更好一些？那就是爭(zhēng)論的主題，以下是適用于一般性的指南：
    ■ Perl 將腳本轉(zhuǎn)換為內(nèi)部可編譯的形式；而PHP 卻不這樣。因此，一旦該腳本通過語法分析，則Perl 可更快地執(zhí)行它，特別是對(duì)于具有大量迭代的循環(huán)。
    ■ mod_perl 可以運(yùn)行腳本高速緩存來提高重復(fù)執(zhí)行的腳本的性能。如果腳本在高速緩存中，則Perl 可更快地開始執(zhí)行腳本，因?yàn)樗恍枰僖淮畏治觥７駝t， PHP 開始執(zhí)行的該腳本的速度更快。
    ■ mod_perl 比PHP 有更大的內(nèi)存覆蓋區(qū)；利用mod_perl 連接的Apache 進(jìn)程比利用mod_php3 的更大。PHP 被假定必須在另一個(gè)進(jìn)程的內(nèi)部協(xié)同存在，并且在那個(gè)進(jìn)程內(nèi)部可以多次激活或撤消。Perl 被設(shè)計(jì)成從命令行作為獨(dú)立程序運(yùn)行，而不是作為被嵌入在Web 服務(wù)器進(jìn)程中的一個(gè)語言進(jìn)行運(yùn)行。這可能使它付出較大的內(nèi)存覆蓋區(qū)；
    Perl是模塊，因此它不運(yùn)行在自身環(huán)境中。腳本的高速緩存和該腳本使用的附加P e r l模塊是付出較大的內(nèi)存覆蓋區(qū)的另外的因素。在這兩種情況下，有更多的代碼使用內(nèi)存，并將運(yùn)行的Apache 進(jìn)程保留在內(nèi)存中。
    在腳本運(yùn)行速度方面，Perl 無論有什么可超過PHP 的優(yōu)勢(shì)，都被PHP 4 除掉了。PHP 4 在它的能力和接口方面類似于PHP 3，但它合并了Zend，Zend 是一種更高性能的解釋程序的引擎。
    無論如何，所有的這些因素只導(dǎo)致Perl 和PHP 的模塊版本之間性能比不同。無論您選擇哪種語言，最重要的是盡可能地避免獨(dú)立的解釋程序。
    解釋程序的獨(dú)立版本的確有一個(gè)優(yōu)點(diǎn)超過它的模塊版本，即可以安排它在不同的用戶I D下運(yùn)行。模塊版本始終運(yùn)行在與Web 服務(wù)器相同的用戶ID 下，出于安全原因，該用戶是一個(gè)典型的具有很少權(quán)限的賬號(hào)。對(duì)于需要特殊權(quán)限的腳本來說不能很好地運(yùn)行（例如，如果您需要能讀寫受保護(hù)的文件）。如果愿意，可以將模塊方法和獨(dú)立方法結(jié)合起來：缺省情況下使用模塊版本，而在具有特定用戶的權(quán)限的腳本的情況下使用獨(dú)立版本。
    降低mod_perl 的內(nèi)存需求
    有些技術(shù)允許您只能對(duì)mod_perl 使用某些的Apache 進(jìn)程。這樣，只對(duì)運(yùn)行Perl 腳本的那些進(jìn)程產(chǎn)生額外的內(nèi)存開銷。Apache Web 站點(diǎn)的mod_perl 部分有可選擇的各種策略的討論（有關(guān)的詳細(xì)信息，請(qǐng)參閱h t t p : / / p e r l . a p a c h e . o rg / g u i d e /）。綜上考慮，也就是說，選擇Perl 還是P H P，您應(yīng)該試著從Apache 模塊中而不是通過調(diào)用一個(gè)單獨(dú)的解釋程序過程來使用它。只對(duì)不能由模塊處理的那些情況使用獨(dú)立的解釋程序，例如需要特殊權(quán)限的腳本。對(duì)于這些實(shí)例，可以通過使用Apache 的suEXEC 機(jī)制在給定的用戶ID 下啟動(dòng)解釋程序來處理腳本。
    5.2.3 開發(fā)時(shí)間
    剛才描述的這些因素影響應(yīng)用程序的性能，但不能只考慮運(yùn)行效率。時(shí)間及編程的簡(jiǎn)易性也是重要的，所以為MySQL 編程選擇API 時(shí)要考慮的另一個(gè)因素是如何很快地開發(fā)出自己的應(yīng)用程序。如果開發(fā)同樣程序，用P e r l腳本只需用C 語言一半的時(shí)間，那您可能寧愿使用Perl DBI API，而非C API，即使開發(fā)出的應(yīng)用程序運(yùn)行速度不是非?？煲踩绱恕？紤]程序的運(yùn)行時(shí)間比考慮編寫程序時(shí)花的時(shí)間更少一些通常是合理的，特別是對(duì)不經(jīng)常運(yùn)行的應(yīng)用程序更是如此。您的一小時(shí)比機(jī)器的一小時(shí)要值錢得多！
    一般來說，腳本語言編寫程序更快，特別是得到應(yīng)用程序的原型更快，這是由于以下兩個(gè)原因：
    第一，腳本語言提供更高級(jí)別的結(jié)構(gòu)。這允許您在抽象的更高級(jí)別上進(jìn)行思考，以便集中考慮要做些什么，而不是考慮如何做。例如， Perl 的關(guān)聯(lián)數(shù)組（散列）對(duì)于維護(hù)具有鍵/值系（如學(xué)生I D /學(xué)生姓名對(duì)）的數(shù)據(jù)節(jié)省了大量時(shí)間。C 沒有這樣的構(gòu)造。如果想在C 中實(shí)現(xiàn)這樣的事情，則可能需要編寫代碼來處理許多低級(jí)的細(xì)節(jié)，其中包括內(nèi)存管理和串操縱的問題，并且需要調(diào)試它，這也要花時(shí)間。
    第二，腳本語言的開發(fā)周期的步驟較少。用C 開發(fā)應(yīng)用程序時(shí)，要經(jīng)歷通常的編輯—編譯—測(cè)試的循環(huán)周期。每次修改程序時(shí)，在測(cè)試之前都必須重新編譯它。而用Perl 和P H P，由于每次修改后不用編譯就可以立即運(yùn)行腳本，因此，開發(fā)周期可簡(jiǎn)化為編輯—測(cè)試。另一方面，編譯程序?qū)Τ绦蛟趪?yán)格的類型檢查形式方面有更多的約束條件。編譯程序施加的更多約束條件有助于避免在松散語言(如Perl 和P H P )中不易捕獲的錯(cuò)誤。在C 中，如果您錯(cuò)誤地拼寫了變量的名稱，則編譯程序?qū)⒕婺?。PHP 不這樣，Perl 也不這樣，除非向它詢問。當(dāng)應(yīng)用程序變得更大且更難于維護(hù)時(shí)，這些更嚴(yán)格的約束條件可能特別有用。
    一般來說，在編譯和解釋語言之間權(quán)衡的是開發(fā)時(shí)間與性能的折衷：是想要使用編譯語言開發(fā)程序，以便在運(yùn)行時(shí)可以更快，但花費(fèi)更多的時(shí)間來編寫它？還是想要用腳本語言編寫程序，以便在縮短編程時(shí)間，但要損失一些運(yùn)行速度？
    將兩種方法合并起來也是可能的。編寫一個(gè)腳本作為“第一個(gè)草案”來快速地開發(fā)出一個(gè)應(yīng)用程序原型以測(cè)試其邏輯性，確定算法的可用性。如果這個(gè)程序有用，并且被頻繁使用，則性能成為關(guān)心的焦點(diǎn)，這時(shí)可作為編譯的應(yīng)用程序重新對(duì)它編寫代碼。這樣做給您帶來兩種方法的優(yōu)點(diǎn)：快速得到應(yīng)用程序的初始開發(fā)原型，同時(shí)得到最終產(chǎn)品的最佳性能。從某種嚴(yán)格的意義來說， Perl DBI 和PHP API 并沒有給您在C 客戶機(jī)庫中沒有的能力。這是因?yàn)檫@兩種API 通過MySQL C 庫連接到Perl 和PHP 解釋程序來獲取對(duì)MySQL 的訪問。然而，對(duì)于嵌入MySQL 的環(huán)境，C 與Perl 或PHP 有很大的不同。應(yīng)考慮在與MySQL服務(wù)器相互作用時(shí)要做的事情并提問每個(gè)API 語言如何幫助您完成這些事情。下面有一些樣例：
    ■ 內(nèi)存管理。在C中，您發(fā)現(xiàn)自己對(duì)任何任務(wù)，包括動(dòng)態(tài)分配數(shù)據(jù)結(jié)構(gòu)都使用malloc() 和free() 來工作。Perl 和PHP 可為您處理這些任務(wù)。例如，數(shù)組的大小自動(dòng)地增加，并且可以使用動(dòng)態(tài)長(zhǎng)度的字符串而不用考慮內(nèi)存管理。
    ■ 文本處理。在這點(diǎn)Perl 具有最大的開發(fā)能力，而PHP 位于第二。比較起來，C 是非常初級(jí)的。當(dāng)然，可以用C編寫自己的庫，將內(nèi)存管理和文本處理這樣一些任務(wù)封裝成更容易工作的函數(shù)。但是，然后還必須調(diào)試它們，并且您也想使自己的算法效率更高。在這兩個(gè)方面，基本上可以斷定，由于它們已經(jīng)具有了通過許多雙眼睛檢查過的好處，對(duì)這些事情Perl 和P H P中的算法一般是易于調(diào)試并且有合理的效率。通過利用其他人的工作可以節(jié)省您的時(shí)間（另一方面，如果解釋程序偶爾有一個(gè)錯(cuò)誤，您可能必須攜帶它，直到這個(gè)問題糾正為止。而用C 編寫時(shí)，可以更細(xì)地控制程序性能）。
    這些語言的不同還在于它們的“安全性”。C API 提供對(duì)服務(wù)器最低級(jí)別的接口，而且強(qiáng)制的原則最少。從這種意義上說，它提供最低級(jí)的安全性網(wǎng)絡(luò)。如果您超出正常順序執(zhí)行API 函數(shù)，則可能獲得一個(gè)“超出同步”的錯(cuò)誤，或使程序崩潰。Perl 和PHP 都提供了很好的保護(hù)。如果您沒有以適當(dāng)?shù)捻樞蜻M(jìn)行，則腳本失敗，但是解釋程序并不崩潰。在C 程序中，出現(xiàn)崩潰錯(cuò)誤的另一個(gè)非?？赡艿膩碓词莿?dòng)態(tài)分配內(nèi)存和與它們相關(guān)的指針的使用。Perl 和PHP 為您處理內(nèi)存管理，所以您的腳本很少可能因?yàn)閮?nèi)存管理的錯(cuò)誤而癱瘓。
    開發(fā)時(shí)間受語言可用的外部支持的影響。C 可用的外部支持是將MySQL C API 函數(shù)封裝為更容易使用的實(shí)例的包裝庫的形式。這些庫對(duì)于C 和C++ 都可用。Perl 無疑具有最大數(shù)量的附加軟件，都是Perl 模塊的形式（與在Apache 模塊中具有的概念類似）。甚至有一個(gè)基礎(chǔ)結(jié)構(gòu)被設(shè)計(jì)來容易地定位并獲取這些模塊（即綜合Perl 歸檔網(wǎng)絡(luò)Comprehensive Perl Archive Network, CPA N）。使用Perl 模塊，不用編寫代碼就可以獲取對(duì)所有類型的函數(shù)的訪問。想要編寫從數(shù)據(jù)庫中生成報(bào)告的腳本，然后作為一個(gè)附件發(fā)送給某人嗎？只要獲取MIME 模塊中的一個(gè)，就立即具有附件生成的能力。
    PHP 沒有同樣程度的外部支持（這并不令人驚奇，因?yàn)樗禽^新的語言）。也許所知道的最佳的附加軟件是P H P基本庫（ PHP Base Library，PHP LIB）。根據(jù)名稱和口令機(jī)制的一些排序，假設(shè)您正在編寫需要限定只有經(jīng)授權(quán)的用戶才可以對(duì)某個(gè)Web 頁面訪問的Web 應(yīng)用程序。可以用任意語言編寫對(duì)它的支持程序，但是如果使用P H P L I B，則不必花費(fèi)時(shí)間重新做這件事情。P H P L I B提供確認(rèn)并且允許通過會(huì)話跟蹤經(jīng)授權(quán)的用戶（從作為單個(gè)邏輯訪問部分的給定客戶機(jī)中連續(xù)頁面的命中）。還可以分配給用戶許可權(quán)，這允許您進(jìn)行像定義具有更多權(quán)限的管理用戶的工作。
    5.2.4 可移植性
    可移植性的問題與為訪問MySQL 引擎所編寫的程序怎樣才能容易地修改為使用不同引擎的程序有關(guān)。您可能不擔(dān)心這個(gè)事情。然而，除非可以預(yù)知未來，否則，說“除了MySQL以外，我永遠(yuǎn)都不會(huì)將這個(gè)程序用在任何其他的數(shù)據(jù)庫上”可能有些冒險(xiǎn)：假設(shè)您找到另一
份工作，并想使用自己的舊程序，但您的新老板使用不同的數(shù)據(jù)庫系統(tǒng)呢？如果可移植性是需要優(yōu)先考慮的事情，則應(yīng)該考慮在API 之間的區(qū)別：
    ■ DBI API的可移植性最好，因?yàn)樗?dú)立于數(shù)據(jù)庫是DBI 設(shè)計(jì)的一個(gè)明確目標(biāo)。
    ■ PHP 的可移植性稍差，因?yàn)樗惶峁?duì)DBI 提供的各種數(shù)據(jù)庫引擎的同樣類型的統(tǒng)一接口。對(duì)每個(gè)支持?jǐn)?shù)據(jù)庫的PHP 函數(shù)的調(diào)用類似于在相應(yīng)的基礎(chǔ)C API 中的那些。稍有一些不同，但很少，需要更改您調(diào)用的數(shù)據(jù)庫相關(guān)函數(shù)的名稱。還有可能要修改一點(diǎn)應(yīng)用程序的邏輯，因?yàn)椴煌瑪?shù)據(jù)庫的借口并不都是以同樣的方式工作的。
    ■ C API 提供的數(shù)據(jù)庫之間的可移植性最差。因?yàn)樗鷣砭褪菫镸ySQL 設(shè)計(jì)的。當(dāng)需要在同一個(gè)應(yīng)用程序中訪問多個(gè)數(shù)據(jù)庫系統(tǒng)時(shí)，獨(dú)立于數(shù)據(jù)庫的可移植性特別重要。這可能包括像將數(shù)據(jù)從一個(gè)RDBMS 移動(dòng)到另一個(gè)RDBMS 中的簡(jiǎn)單任務(wù)，或更復(fù)雜的任務(wù)，如基于從許多數(shù)據(jù)庫系統(tǒng)中得到的信息生成報(bào)告。
    DBI 和PHP 都提供對(duì)訪問多個(gè)數(shù)據(jù)庫引擎的支持，所以對(duì)不同的數(shù)據(jù)庫，甚至在不同的主機(jī)上，都可以很容易地同時(shí)連接到服務(wù)器上。然而， DBI 和PHP 在對(duì)于從多個(gè)異構(gòu)數(shù)據(jù)庫系統(tǒng)中檢索和處理數(shù)據(jù)的任務(wù)的適宜性方面有所不同。而DBI 更好些，因?yàn)闊o論使用哪種數(shù)據(jù)庫，它都使用一組單獨(dú)的訪問調(diào)用。假設(shè)想在MySQL、mSQL 和Postgres 數(shù)據(jù)庫之間傳送數(shù)據(jù)。使用DBI，則使用這三種數(shù)據(jù)庫的惟一不同之處在于用于連接到每個(gè)服務(wù)器的DBI -> connect( )調(diào)用。而用PHP時(shí)，可能需要有更復(fù)雜的腳本，該腳本將含有三組讀取調(diào)用和三組寫入調(diào)用。
    多數(shù)據(jù)庫應(yīng)用程序的一個(gè)極好的例子是MySQL 分發(fā)包中的crash-me 腳本，它可測(cè)試許多不同的數(shù)據(jù)庫服務(wù)器的能力。該腳本是用D B I編寫的，對(duì)于這樣的應(yīng)用程序，這種選擇是很明顯的，因?yàn)槟梢酝瑯拥姆绞皆L問所有的數(shù)據(jù)庫。