這個問題嘛～我個人是覺得有圖有真相，看一下這篇：
http://blog.felho.hu/what-is-new-in-php-53-part-3-mysqlnd.html

我能確定的是，無論如何，在取回結果時，那些結果的資料有一份副本在PHP所管理的記憶體中（否則 php便無法存取它）。
但是這個複製資料的機制，我並不確定是否在query完成之後便會啟動。

另外，對於石頭所說的：
引用:
以及
引用:

這點持保留意見，因為我去翻過PHP的原始碼，找不出 mysql_query 有改成跳過 memory_limit 的地方。

如果石頭有找到，請幫我指出來～

另外，從我個人貧乏的實務經驗裡，我看不出來如果必須要知道某個查詢的總筆數跟內容時，為何總筆數要在內容後去查詢？

一般而言，會先查出總筆數，再根據其數目作分頁～
或者根本不管總筆數為何，直接用頁碼跟每頁幾筆直接作分頁查詢。

另外之二，假設內容資料是非常龐大的，且必須利用查詢內容作某些運算（例如：矩陣運算之類的），那麼這樣的應用不該由PHP程式來完成，應由其他的方式來作計算（例如：資料庫作OLAP或是Server上某個用C/C++寫的程式定期跑），Web這邊只做顯示以及計算排程即可。

看得好累....

1. 請先看一下 mysql C API 的 mysql_store_result 和 mysql_use_result 再來說道理.
mysql 不可能以資料直來直往的方式把結果回傳給 user , 因為一個 mysql_query 就把資料直接全部倒給 User . 如果msqyl系統這樣設計的話, 就真的太恐怖了, 一個 user 的 select * from any_large_table 就可能把系統撐爆.

2. result set 應該是指結果集, 並不是指資料 row. 應說像是資料Row的抽象資料, 雖然會比實際的資料Row所使用的空間小許多, 但在筆數太大的情況下, Result Set 仍然可能變得很大(請注意大小是與資料筆數有關, 而不是與每個row 的資料大小有關). 從 PHP Large result sets and summary tables.這個 Blog 中可以看到 Result Set 是可以放在 PHP 端或是 mysql server 端 .

而為什麼要考慮result set兩種方法? 看起來是為了效率和空間的考量.
重點是在資料筆數的多少, 如果在不超過一定筆數(要看PHP端的記憶體配置), 用 mysql_query 是 OK 的, 而且因為 Result Set 就放在 PHP 端, 所以速度上也會比較快.
但如果筆數過多, 則必須採用 mysql_unbuffered_query , 以每次讀取 Result Set都要詢問Server , 換取 PHP 端記憶體的空間.

該用哪一種方法要看系統的環境如何.

3. OO 在各個語言的好壞是見仁見智的, 一般使用者只會看開發工具及支援廠商. 和 OO 的表現方式關聯不大. (要不然是不是大家都要學 small talk??) 重點在習慣每個語言 OO 的特性, 才能寫出一個漂亮的程式.

4. 一般的評價上, cakePHP 的確有它的缺點, 但是只要慬得避開缺點(像 FIEND 提到的 cakePHP 對大型資料庫的效率問題, 試問有多少人會用到大型資料庫??) , 一樣可以完成一個系統.


5. 而 MVC 和多層式架構本來就不是該放在同一個水平上比較的, MVC 因為把系統切成多個 Model-View-Controler , 所以多人或漸進式的開發和維護上比較方便; MVC 內部一樣可以切分很多層級, 所以只能說 MVC 並不完全 follow W3C 的多層式架構; 我覺得兩個架構應該是相輔相成的.

看到上面的討論, 只能讓我想到"文人相輕"這個成語; 系統本來就有很多面向的思考方式, 各種架構都各有好壞, 只能以各人習慣與使用範圍來決定各人的喜好.
在我以往的經驗上, 很難只用一種程式寫法就能走天下. 我覺得要能夠適應系統限制, 找出適合使用的架構和流程, 才是一個合格的程式設計人員.

在表達自己的意見之外, 也該多想想別人的講法是否正確,
是否該調整自己的想法?

感謝各位，這個討論串讓我收穫良多！

不過，FIEND 的以下這段的說明不對喔！

#########################################

網站程式 多層式架構設計 觀念 是在 mvc 還沒有出來前就有了 ..

#########################################

internet 開放給商業使用是在 1992 年左右，網站程式更是在那之後才發展的。資料參見：

History of the Internet 的 6 Opening the network to commerce

而 MVC 模式則是在 1979 年被提出，1987就已經被實做出來。資料參見：

Model-view-controller - Wikipedia

另外，對於 query 之後，資料在何處的問題，提個想法。不知能不能將 web 程式放在 Server A，MySQL 放在 Server B，實際觀察看看，是否就能確定了呢？

對 MVC 的年代做更正：

MVC 最遲是 1978 就已被實做出來，所以 MVC 觀念應該是在那之前，就已經被提出。

資料來源：XEROX PARC 1978-79

很多深入的討論都是靠"文人相輕"來的. 太客氣的話,大家都是點到為止,辯不出真理!!
我在旁邊看的很高興勒,雖然大部分都看不懂

引用:


哈　～沒錯　後來我去看　ｗｉｋｉ　ｍｖｃ　的說明　．

１９７８　年就出來了．

而且　ｍｖｃ　比　ｍｆｃ　還更早．

更有人說過　ｍｆｃ　是　ｍｖｃ　的失敗作品　．

原來我也是印象泒的．

沒有去求證．

謝謝指正．

＃＃＃

哇 天啊!~~NORMAN 老大　來了　^^!! ...

謝謝 老大 提出 更具體的答案 .

我的經驗 比起您來差太多了 跟人家辨論像墨魚一樣

謝謝您的指點.

##########
引用:

您客氣了我 也學到很多東西...

謝謝大家給小弟的意見和指教.

引用:

一般而言大家的理解都是這樣,
但是我看到 FIEND 的程式中,
內容和分頁是在兩個不同的 MVC 模組中,
所以才會出現要下兩次 QUERY 的情況.

似乎 cakePHP 在這個部份的架構設計的怪怪的.

引用:

Web 上的經驗我還算是新手而已...

只能說工作的時間比較多, 看過的系統也比較多一點.

引用:

是啊...

其實 db 可以一個 query 就把 資料全拉回來.

很多 db system 根本連 limit 都不削使用．

把　ｌｉｍｉｔ　的記憶從自己腦裡清除．

就可以知道為什麼我覺得　ｃａｋｅ　在這段的設計上

讓我覺得　設計的很不好．




引用:

是啊~

本來我的個性也是 覺得會得罪人就不敢再討論下去.

很多年前 .

剛好也是為了 db query 的問題跟同事辨論了好久.

例如 :

db 撈回資料會全數放在 php陣列的看法.

在 很久以前（大楖六年前吧） 因為自己不是科班畢業的 只看結果

所以 我也以為是這樣.

後來在一次的在跟同事的辨論中 , 我才發現自己錯的太嚴重了.

db 下 query 頂多 會把一些 key 做好 放在 db 端和 php 端做對應.

如果全部都要拉成 arryay 一定會灌 爆 server .

如果 不打破沙鍋辨論到底.

就不知道自己錯的有多誇張.

所以小弟的討論風格　會比較講求實證和比較站的住腳的理論．

這裡也跟　"shirock" 老大說聲報歉 , 若您可以提出更有利的證據來證明

您提出的 結果是對的.

小弟會很感謝您給小弟上了一堂免費的課.

FIEND,

你提到：

引用:

能否請教一下，就我知道除了 Oracle, SQL Server 2005 不支援 LIMIT 外 (所以只好提供變相的 ROWNUM 、 ROW_NUMBER 等方法) ；請你把這些 DB System 列出來讓我們參考，我很有興趣知為什麼這些 DB System 不「屑」 LIMIT 的理由。

另外也要請教你如何用一次 Query 就可以做到分頁的方法 (而且要能顯示) ，除了上面 tokimeki 提到不理會總筆數的方法以外。

我個人所做過的方法是先將總筆數算到另一個表格，但這還是得要兩次 Query 才能完成 (一次抓總筆數、一次抓該分頁的資料) 。

引用:

討論是好事一件，尤其技術含量高的討論更是讓大家意猶未盡。不過身為朋友，我強烈建議你的用詞應該多加以考慮，很多時候這就是你得罪別人的原因。因為也許你寫者無意，但看者有心。

至於其他方面，就我淺薄的知識，就只能同意 tokimeki 和 normansu 的部份了。

===

...這個論壇只有版主才能編輯自己的文章...Orz引用: