→ LaPass:你說的是對的..... 工作上常常看到反正規化.... 11/05 09:29
推 jl844032:受教了! 11/05 23:25
※ 引述《jl844032 (湖藍者)》之銘言：
: 如題
: 想請問版上大德們
: 一個PHP想要從MYSQL拉資料後 再用PHP做運算比較好
: 還是在MYSQL做完運算後 傳回來PHP比較好
這個問題是個大哉問啊...
: 關於效能方面 哪個方式會比較好?
我有兩組答案，一組是業界的，一組是學界的...
不管是哪一種，談「效率」的時候前提都是假設在「資料量夠大」，所以下面就
不再提醒資料量的問題了，都是以資料量夠大為前提...
=======================================================================
學界的比較簡單，用 MySQL 算「整體」上會比較省資源，而且考慮到傳輸數據也
是成本，用 MySQL 算比較省資源通常都是對的。
反例是 MySQL 內建的函式沒辦法快速處理時，拉到 PHP 端計算可能會比較快。
=======================================================================
業界的答案就很複雜了，要列出不同的情境...
對於只用過 MySQL MyISAM 的人，答案 100% 是 PHP 比較好，因為 query 如果
跑很久的話，會導致 table 卡住無法寫入...
=======================================================================
接下來是會用 InnoDB 的人，又要再分成公司的狀態...
如果公司 Programmer 比較強勢，那麼 Programmer 會希望事情不要在 PHP 端計
算，會壓榨管資料庫的人要把資料庫弄強...
會出現的用語：「這個是資料庫不夠力的問題」。
如果是管資料庫的人比較強勢，那麼會壓榨 Programmer 把計算丟到 PHP 端。
會出現的用語：「這個不應該歸資料庫計算」。
=======================================================================
最後是講比較美好的情況：這個問題是依照商業邏輯而決定怎麼做比較好。
我們知道在資料庫端算完再丟出來對整體的資源是最省的，但我們也知道資料庫
是最難以擴充的部份 (相較於 PHP 端)。
在知道這個前提下，針對不同的商業需求來決定要怎麼處理。
不過這有個大前提，現在幾乎都應該用 InnoDB 了啦，不用 InnoDB 受限太多...
對於 Web 應用來說，為了要壓力頁面產生時間，有很多東西會在 MySQL 上反正
規化，然後用 trigger 更新；或是反正規化後用 transaction 確保資料的一致
性。
而對於報表來說，反正每天用離峰時間慢慢跑就好：第一是因為離峰時間，本來
就有多出來的計算資源可以用，第二是報表類的東西不需要即時計算，慢慢跑完
就好，去正規化之類的事情能省就省...
=======================================================================
這是我的想法啦，不能接受的人還蠻多的 XDDD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.242.135.97