PHP為什麼會被認為是草根語言？

　　以下文字並沒有非常多的技術詞彙，所以只要對PHP感興趣的人都可以看看。

　　PHPer是草根嗎？

　　從PHP誕生之日起，PHP就開始在Web應用方面為廣大的程式設計師服務。同時，作為針對Web開發量身定製的指令碼語言，PHP一直秉承簡單、開源的思想，這也使得PHP得以快速的發展，並且大力地推動Web2.0的出現與發展。但是，長期以來，PHPer(PHP Programmers)被認為是處於草根階層的程式設計師，被認為是技術含量少，層次低的程式設計師。這點在國內尤其突出。

　　記得一個技術主管說過這樣一個事情。他給一個程式設計師分配了PHP的開發任務，沒想到那個程式設計師居然說：“我是學Java出身的，你讓我去寫 PHP，你這不是在貶低我嗎？”。這件事情給我印象很深、觸動也很大。雖然這不能代表大部分程式設計師的看法，但是這麼認為的人應該不少。還有人說，現在如果是大型的政府專案，PHP是肯定不會被列入考慮的範圍之內的。

　　那麼為什麼PHPer會被認為是草根階層，是因為它很簡單，人人都可以學會，所以沒什麼難度嗎？我以前也是這麼認為。PHP入門很快，處理檔案，資料，遠端連線，網路程式設計都非常方便，官方也有這樣的說法：PHP學習的成本很低，所以你容易去使用它。這個想法也是普遍的，甚至大部分的PHPer 自己都這樣認為。

　　說到這裡，我想大家就會想到我為什麼要寫這些文字。因為一年多的PHP推廣工作讓我瞭解到許許多多的使用PHP的公司的大概情況。在這些過程中我慢慢體會到其中的根本原因。這裡我說是根本原因雖然是個人的看法，但是我覺得事實就是如此。

　　那麼為什麼PHPer會被看成草根階層，根本原因是PHPer所作的事情(通過程式碼實現)的絕大部分都是表現層的東西，這個熟悉PHP的人都知道。當然也會有PHP會說他用MVC結構編寫的某某框架具備的如何如何的功能。但是這些還是表現層。所以只會處理表現層的程式設計師就被看成草根階層了。事實上也是如此，因為這種情況下PHP確實很難構造大型的應用。

　　這就找到原因了，不是的。為什麼PHPer總是在負責表現層的東西呢。答案是底層的資料處理(Web應用就是資料儲存和查詢)我們一般不去觸及。好，那麼說到這裡有些人可能已經想到了，那不就是資料庫嗎？對，就是資料庫。讓PHPer一直當草根的元凶就是資料庫。為什麼？

　　PHPer對MySQL的依賴過大

　　因為目前流行的web架構中，前端是負載均衡系統，中間是web伺服器，後面是資料庫伺服器。所以，大部分PHPer工作在Web伺服器層面。因為資料庫已經很好地為我們組織資料了。所以PHP中沒有太多的演算法，而且大家潛意識下也覺得不需要，更何況會影響效能。

　　這種情況下，PHPer就成為了資料庫使用者，他總是在運算元據庫。而不是在做程式。一個最簡單的PHP指令碼就是，連線資料庫，把資料取出來，然後用命令輸出到瀏覽器。整個過程不超過10行程式碼。給人的感覺就是太簡單了。沒有任何技術含量。為什麼了，因為資料處理部分都已經被資料庫做完了。尤其是MySQL的使用。MySQL是免費的，所以大多數程式設計師可以自由地使用它，另外MySQL的速度夠快了，所以做個PHP應用程式非常的簡單。這就相當於給你槍以後你覺得沒有必要學習武功一樣。當然，我不是說槍沒有武功好。而是說，槍的出現，小孩都可以輕鬆便捷地殺人了。

　　我們再詳細說說為什麼是資料庫。這裡我說一個例子。我去過北京一家非常著名的網站，當時我們還有一個比較資深的PHP程式設計師在那說些系統架構的事情。我記得當時那個程式設計師問大家一個資料結構中的演算法問題的時候，全場沒有一個人能答得出來(包括我)。然後那個程式設計師就開始給大家講些很基礎的資料結構的東西了。讓我一下子回想到大學時候學的資料結構課。而這些基礎的資料排序、查詢、傳遞的問題在其他高階語言(比如C)是非常普遍的。但是在PHP沒有。PHPchina.com的論壇也有個板塊叫PHP的資料結構和演算法。這個板塊的帖子也是寥寥無幾。

　　說到這裡，大家明白了吧？大部分PHPer僅僅處理表現層的東西，而在MySQL的便捷使用下，PHPer幾乎不用觸及任何資料結構與演算法的情況下完成大部分開發任務，所以一個才有上面的，沒有一個PHP程式設計師能夠回答出那道資料結構的問題，換成是C等語言，情況可能就大不相同了。是PHPer草根，才讓PHP顯得草根。

　　仔細回想下，目前網路上大家討論的最多的是兩個方面的問題。一個是PHP的類的使用(處理過程的封裝)，還有一個是開發框架問題。但是我們仔細分析的話，發現這些所謂的PHP中比較複雜的概念裡面沒有資料處理。為什麼，有資料庫。用一個Adodb或者PHP5的PDO就可以搞定了。真的搞定了嗎？不是，這些無非是在連線資料庫，沒有資料處理。所以PHPer似乎就沒有什麼可以拿出檯面上的東西。

　　再說一個具體的程式碼問題，無級分類。這個概念我想大家都不會陌生了吧。我見過兩種處理方式。第一個是地道的PHPer的處理方式，也是目前比較流行的。就是用資料庫來處理。而且欄位很少，只需要加個父類的欄位並加以判斷就行了。而且這個方法很實用。效率也高。但是這個不是資料處理的範疇了，而是資料庫的查詢。

　　第二個是C程式設計師用PHP寫出來的，他把所有的分類資訊都從資料庫取出來，然後用資料結構演算法進行排列分佈，然後輸出。

　　這裡我們不對這兩種方式的效率進行對比，我想大家都有各自的想法。但是我想說明一個問題，就是這兩種做法的本質的區別。PHPer習慣性地用資料庫來處理，而且有很巧的處理方式，效率也很高。這種方式就是資料庫查詢。而第二種方法是比較有特點的。他認為資料庫就是存放資料的地方，具體的邏輯處理還要靠自己的邏輯。

　　因此，結論是第二種方法的使用者覺得自己強些，因為資料的邏輯是他組織的。並且覺得PHPer的那種做法無非就是會查詢資料庫罷了。所以他認為PHPer是草根級的，只懂得運算元據庫和排列頁面(smarty搞搞那種)。

　　讓資料庫迴歸本職工作

　　說到這裡，我想大家都已經回憶了不少自己平時用PHP做開發的經歷了吧，是否發現大家確實都在運算元據庫呢。

　　那麼我們來討論下這個問題。資料庫不好嗎？為什麼我一直用資料庫處理資料都沒有問題。我要說的是資料庫是有問題的，而且有很大的問題。當然這裡我並不是說不能用資料庫，也不是在貶低資料庫的效能。而是，我們沒有充分認識到資料庫所起到的作用。

　　我的想法源起於這樣一個事情，有一次一個網站的技術總監問我，為什麼他們的網站那麼慢，要怎麼辦。當時，我的MSN裡Zend總部的工程師正好線上，我就問他PHP響應比較慢了，怎麼辦？他當時直接告訴我，是資料庫問題。肯定是資料庫沒有優化設計好。所以，我沒有給那個技術總監確切的答案了，因為他們的資料庫設計我們是不能涉及的。所以就給了大概的資料庫優化的建議。這樣的事情屢次發生，我就開始懷疑，為什麼Zend總部的工程師每次都跟我說是資料庫的問題呢，難道我們不能從PHP層面來解決這個問題嗎？答案是不能。因為PHP目前的執行速度已經是很快了，通過Zend的效能分析也能看到一個使用者的點選，PHP的執行時間只有10%不到，那PHP在幹嗎？它在等。等資料庫的查詢結果。這個方面在目前的PHP產品中有了很大的提高，那就是 Caching和網頁靜態化兩個方案。

　　Caching可能大家會比較陌生，但是網頁靜態化現在連PHP產品的使用者都非常清楚了。速度快、容易被搜尋到等等，好處不言而喻。開玩笑地說，現在網站的主頁實現網頁靜態化只需要硬碟足夠大。J至於Caching就比較複雜些，也是大多數PHPer感到頭疼的地方。甚至於有些人會用C來實現。因為Caching中的資料有效期驗證、查詢、提取、更新等等都是比較難處理。當然，也有人會用資料庫來處理 Caching問題。

　　所以，當訪問量激增的時候，PHP架構的網站會出現的很多問題都因資料庫而起。資料庫的同步問題還不算什麼。關鍵是資料庫的響應速度會有指數級的降低。這個問題我在10月23號LAMP釋出會的時候問過MySQL的副總裁。他當時也沒有給我比較完美的答案(這也我的意料之中)，因為資料庫總會有瓶頸的，除非是神仙資料庫，哈哈!

　　這裡有個題外話，LAMP大會的時候我跟Yahoo的一個技術高管聊的時候，我問他Yahoo在選擇MySQL還是Oracle的時候是怎麼考慮，他的答案令我非常驚訝。他說大部分的時候我們是會用MySQL的，因為它的效能已經達到我們的要求。但是什麼時候我們會選用Oracle呢，就是當我們需要儲存收費使用者的資料的時候。我就問為什麼，難道Oracle比MySQL穩定嗎？他說，這個倒沒有特別考慮。關鍵是如果使用Oracle的話，當出現問題的時候我們可以找到負責人，Oracle會負責事故的處理，但是如果用MySQL的話，我們找誰去?

　　所以，我們對資料庫的看法應該糾正過來，就是說資料庫不是萬能的。如果有實力的話自己開發資料庫。聽說Google就是那樣的。

　　那麼我們怎麼看待資料庫呢？我個人的理解是資料庫只是用來降低開發成本的手段。因為採用資料庫以後我們不需要考慮資料的儲存，尤其是排序和查詢。但是這會帶來什麼問題呢？就是當業務膨脹的時候，資料庫就成為瓶頸了。這個時候問題就會非常棘手。因為這個是底層的資料處理。牽一髮而動全身。

　　所以我認為正確的觀點是，資料庫是一個資料備份機。怎麼理解，我們只需要保證資料的儲存有效性就行了。而這本來就是資料庫的核心功能，只不過因為資料庫的方便的排序等功能讓大家把過多的處理都交給資料庫來操作了。一個使用者的點選PHP就把一大堆的任務交給資料庫，然後把結果排列下給使用者就完事了。這對資料庫是不公平的。也是因此大家開始抱怨資料庫的效能了。

　　針對這個觀點，我們再舉個例子，有一次我去拜訪一個大型的網路公司(基本上國內只要上過網際網路的都知道)，他們使用PHP很少，但是我瞭解到他們其它業務是怎麼使用資料庫。他們自豪地跟我介紹說他們在資料庫的外圍有個第二資料庫(我這裡起名叫第二資料庫)。為什麼叫第二資料庫呢，原來它是一個快取系統。那麼開發工程師怎麼去這個快取系統獲取資料呢？那個技術總監自豪地說，他們這個快取系統有SQL查詢語句。我當時很驚訝，但是後來想想確實需要這個。因為當你的快取系統達到一定量級的時候從快取獲取資料都非常複雜，乾脆寫個SQL查詢語句讓快取系統分析、處理並返回資料。而且他們告訴我，在他們那裡，就算是用PHP的話也是讓PHP去那個快取系統讀取資料。

　　所以說，如果你能處理好這樣的問題的話，把資料存放在資料庫，然後資料庫只起到備份的作用。然後你用自己的中間層來處理分析資料，效果是90% 以上的使用者不訪問資料庫。有人就會說了，這不就類似連線池的東西嗎？是的，因為資料庫的瓶頸是無法解決的，我們只能在Web伺服器和資料庫中間加個中間層來做緩衝。

　　可能大家會說了，切，這個我們早就知道了。那好，這裡我要說的是它引發的兩點思考：

　　第一，有些語言已經有連線池技術的基礎上，那些程式設計師可以方便地使用連線池而構建大型應用。那麼如果他們認為 PHPer只會是用資料庫，那麼我們是不是可以說他們只會是用連線池呢？連線池和資料庫在這個概念上有何區別？

　　第二，當PHPer開始構建自己的快取系統的時候，他是不是突破了PHPer只會是用資料庫的層次？因為他參與了資料邏輯的處理工作。那麼他還是草根嗎？

　　最後，懂得獨立思考的PHPer不是草根，什麼事情都丟給資料庫去做的才是。