


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