※ 引述《gpmm (銀色)》之銘言：
: persistent connection 也太暴力了… orz
: 這種小弟都習慣從設計模式上處理，Factory 也好 Singleton 也好，
: 只要確保一隻 php 只會開啟一個 db connection，
: 盡量縮短佔用時間（從 SQL 數量和資料異動量著手），
: 然後看能不能把 ORM 一起做掉（咦）
用pattern是滿好的 不過我滿懷疑pattern用於web app的效用
像Singleton 應該是只能確保同一個request 是用同一個連線
同一個人 「重新整理」同一隻php 就會是不同的request
就會產生不同的instance 就會是不同的連線
其他人開同一隻php 也是不同的連線
同樣用pattern 感覺web app與一般程式語言的用法不同 需要有所調整
關於pattern如何用於web app 值得另外發文討論
: connection 數量有限沒錯，拿完了後面的 http 就要開始領號碼牌等叫號了，
: （也就是一般 client 端網站跑跑跑就是開不起來的其中一種情形）
: 所以網站在達到一個規模之後都會變成多主機的架構（像 Master-Slave* ）
: 可是一旦拓展成架構，SQL 指令數量和異動資料數量這兩樣的影響力就會
: 被狠狠放大（因為不同主機之間資料同步的關係）
: 有時在 Master 下了一道看似非常簡單的指令，
: 可是 sync 過去的時候竟然在 Slave 上硬生生給卡住，
: 只因為異動的是一個被關聯的資料表，充滿了 index table 需要一併更新，
: 導致其他 JOIN SELECT 的 SQL 全數凍結…
多主機不是應該比較威嗎，分散運算？
結果做備援/鏡像用時，反而卡在同步…
這同步不是即時的吧，也就是 Master 完成一個階段後，再餵給 Slave？
會不會是因為 Master 累積的量太多， Slave 一時消化不完？XDDDD
謝謝分享，沒相關經驗，不是很能體會。
: : 用同一個連線比較省:P
: : 省還要更省 讀取db次數最好介於0~1次
: : 寫入db應該也盡量不超過1次 (善用外鍵FK 可一次寫入多個table)
: 利用 FK 一次寫入多個 table，有沒有例子可以介紹一下呢？ o_oa"
只是在說關聯資料表而已 比如將table a 某個人的cname值改成"xxx"
其他table b, table c有設FK的cname 也會同時被改成"xxx"
: : 都只query view，更新都只更新原table的change欄位一次(一個sql指令)，
: 這個當初有想過，可是實際上用筆移動幾次後，
: 發現已經快 SELECT 不出來順序了 XD
嗚 中看不中用 跑個幾次就經不起考驗了？ T_T
不過它的設計理念 應該還可以再多加發揮
就是原來的東西不要動 加上別的東西去影響原來的東西
並組合成新的東西 (蛤~什麼東西？XD)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.122.76.198