MYSQL優化和設計規則：PHP方法VS本地主機

在MySQL程序，我不知道這是一個愚蠢的問題，但我有這個兩個疑惑也許你可以幫我清除出：MYSQL優化和設計規則：PHP方法VS本地主機

如果我的數據庫和Web服務器位於同一主機上，是否有任何相關優勢，使我的過程有條件地從SQL數據庫過程中的表中選擇（使用多個SQL查詢）元素，而不是僅在Web服務器端腳本中實現它們（在我的案例PHP）的方法與其他的Web應用程序代碼？

其次，甚至更重要的是：我是否違反了任何設計規則？

更具體地說，我做了一個PHP腳本，根據各行的前一個選擇的數量確定的概率密度函數，這是這樣的，從表中選擇一個隨機行：

function acceptation_rejection_method($link,$tablename,$column,$condition="") 
{ 
    $max=get_col("max(".$column.")",$tablename,$link,$condition); 
    $min=get_col("min(".$column.")",$tablename,$link,$condition); 
    $bar_value=mt_rand($min,$max); 

    $count=get_nelements($tablename, $link,"where ".$column."<=".$bar_value); 
    $selected_row=get_row(mt_rand(0,$count-1), $tablename, $link,"where " 
    .$column."<=".$bar_value); 
    return $selected_row; 
}

我函數實現接受拒絕方法（http://en.wikipedia.org/wiki/Acceptance-rejection_method），我的問題是：考慮到我的數據庫和我的Web服務器位於同一主機上，是否有任何改進將該腳本重寫爲返回行的SQL代碼？（假設我的應用程序的所有用戶都在不斷地使用它，就像每個請求中的一樣）

來源

2011-11-25 NotGaeL

看來你沒有清理你的$ column，$ table和其他變量 - 這是一個突破一些設計規則肯定 –

symcbean是正確的，你在這裏專門討論的模型 –

MVC提到刪除流行的索賠，在調用mysql_query之前在get_nelements，get_row和get_col中執行清理，但是也許我應該在$ bar_value之前檢查$ count以及$ min和$ max值。感謝提及 – NotGaeL

如果我正確地解釋你的問題，你想知道你是否應該編碼您接受/拒絕算法成一個純粹的數據庫功能，或者你在這裏所做的是「正確的」，無論從建築和表現的角度來看。從性能的角度來看，如果有一種方法可以將查詢表示爲單個SQL語句，那麼它可能會比當前的實現更快，但是（假設列是索引的），可能並不是那麼多更快。

你可以，當然，創建一個存儲過程 - 但它看起來像你在多個表和列運行這一點，所以你最終有很多的存儲過程。

存儲過程有優點和缺點，但在這種情況下，我會說，他們使應用更加脆弱。再次，我懷疑你是否會看到巨大的性能影響。

建築上，我覺得你在做什麼很可能是乾淨的解決方案 - 你背後抽象的單一方法的算法。

來源

2011-11-25 17:24:32

感謝您的洞察力，我對SQL程序和SQL的知識一般都非常有限，而且我不知道存儲過程方法何時是最聰明的解決方案（儘管如此，我正在努力學習更多關於此方面的知識他們看到了我的需求，只是想知道哪種解決方案在一般情況下更好，針對我的情況，並且您非常清楚地回答）。 – NotGaeL

我懷疑形式從同一個源請求相同的數據無所謂。

假設我的應用程序的所有用戶在每次請求

~~經常使用它，像幾乎一次，然後你可能要考慮不斷變化的辦法。~~

對不起，我與自己矛盾。

首先，您必須對您的代碼進行配置並查看是否有任何問題。

只有如此，那麼您可能想要考慮改變方法。假設您可以一次請求所有數字，隨機化它們並將其存儲在內存緩存中。然後只需要逐一請求，使用後刪除。刷新排氣。

來源

2011-11-25 13:38:43

嗯，它實際上並沒有很大的麻煩，只是想知道如果它適用與否。一次完成所有請求在這種情況下並不是有用的，我肯定會採納這個建議並將其應用於我現在正在處理的另一個案例。 – NotGaeL

在一個簡單的MVC架構的設計，其中數據庫和Web服務器在同一臺主機

嗯嗎？ MVC是一種設計模式，不是系統/服務架構。

是那裏把我的程序有條件地選擇SQL數據庫程序中（使用多個SQL查詢）元素從表而不是隻在一個web服務器端腳本實現它們的任何相關利益

首先，對於相同的人羣，無論您是在查看整個樣本還是隻是一個子集，都不應該需要「多個SQL查詢」。即無論您如何實施它，您的算法都存在缺陷。

其次，使用腳本你拖大量的數據庫和PHP腳本，這是一個開銷之間的數據。您正在使用PHP處理大量數據。 PHP沒有明確的設計形式來處理大數據集--SQL和PL/SQL。如果你在數據庫上做了儘可能多的處理，那麼你的應用程序應該運行得更快，代碼更少。

來源

2011-11-25 13:49:51 symcbean

好，然後更改爲第一行的「在一個簡單的MVC設計模式設計...」（對不起，這不是一個藉口，但英語不是我的母語，因此麻煩）其實，使用腳本我做4個querys ，其中3個返回一個數字，另一個返回選定的行，所以PHP需要處理的「大量」數據是3個數字（我是對嗎？），實際開銷是3個請求的數量，而3個數據是真的短答案。不知道這是否是一個效率漏洞，但無論如何，對於操縱查詢輸出大量數據的最常見情況來說，肯定會有一些考慮。 – NotGaeL

MYSQL優化和設計規則：PHP方法VS本地主機

回答

相關問題