2016-01-11 29 views
3

我有一個應用程序有很多的查詢,在多個地方重複使用。什麼是最有效的方式來存儲這些?我的直覺是將它們存儲在數組中的一類,即:如何在PHP應用程序中高效地存儲sql?

$sql['report 1'] = "SELECT this FROM that WHERE expression"; 
$sql['report 2'] = "SELECT this FROM that WHERE expression2"; 

誰曾使用沒有開關情況下,對參與這個項目的另一個開發者:

switch($query){ 
    case 'report 1': 
     $sql = "SELECT this FROM that WHERE expression1"; 
     break; 
    case 'report 2': 
     $sql = "SELECT this FROM that WHERE expression2"; 
     break; 
} 
$result = runquery($sql); 

另一個我的想法是,每個報告應該是它自己的功能:

function report1(){ 
    // run the query here 
    return result; 
} 
function report2(){ 
    // run the query here 
    return $result; 
} 

我更喜歡陣列我因爲它看起來像更乾淨的代碼,但由於有大量的查詢,在內存使用方面是不是浪費?是不是所有的查詢都會保存在內存中?

開關盒的方法似乎有點笨拙。這些方法的優點和缺點是什麼?有沒有一種方法能夠突出這種「最佳方式」?或者也許另一種我沒有考慮過的方法?

+0

不要「存儲」SQL查詢。在一個地方定義它們並調用該函數。 –

+0

老實說,我也有很多查詢運行,我不保存在任何地方。我正在用一個querybuilder類編寫它們。例如。 '$ sql = querybuilder :: newInstance() - > table('settings') - > select(「*」); //返回PDOStatement對象。這看起來像是浪費了磁盤空間,但是如果您想要從該表中獲取更多指定或不同的數據,您現在會添加其他功能嗎?我只是將更多的方法添加到上面的列表中(或其他開發人員將只擴展sql字符串)。老實說,我沒有看到使用數組,開關或函數只返回SQL數據的親。 –

+0

我同意@juergen。最好的方法是創建一個存儲庫類,其中包含如下方法:'public function getReport1()',它包含SQL查詢並獲取結果。然後很容易將存儲庫類與依賴注入等交換以用於測試/更改存儲。 –

回答

0

很久以前我遇到過這個問題。驅使我們解決這個問題的一個痛點是,我們在遍佈代碼的SQL查詢中看到了大量的重複。我們有自己的本土MVC框架,我們有簡單的數據庫訪問封裝類,但是我們經常在多個模型類中找到相同的SQL查詢。我們當時覺得沒有必要將SQL分解爲數據訪問層中的單獨函數 - 這樣做會更乾淨,但它會在架構中引入一個全新的「層」,並且額外的沒有必要複雜的一層。我們也不想讓模型類更加細化 - 我們承受了很大的時間壓力,團隊認爲基本結構沒有造成任何痛苦 - 這只是SQL查詢的重複傷害。

我們的解決方案非常基礎。我們爲每個查詢創建了一個包含變量的PHP文件(它不像您所描述的那樣是一個數組,每個查詢只有一個變量)。我們用大寫字母表示法來表示它是「常量」。我們用評論大量地散佈SQL文件,並使用命名約定來幫助開發人員理解意圖,而不是技工。例如:

$REPORT1_GET_THIS_FOR_EXPRESSION = "SELECT this FROM that WHERE expression"; 
$REPORT2_GET_THIS_FOR_EXPRESSION2 = "SELECT this FROM that WHERE expression2"; 

我們將這個PHP文件包含在所有模型類中。是的,它佔用了內存,但不像你會注意到的那樣 - 事實上,內存使用率可能更低,因爲在運行時,這些相同的字符串在其他源文件中不會被複制。

這對我們的(小型)項目很有效,有3個左右的開發者,都在同一個房間裏一起工作。我們的老闆很看重可維護性或可擴展性的上市時間,而且這個工作非常好。代碼是可讀的,我們可以在一個地方更改SQL查詢並修復大量的錯誤。

我不會使用「switch」語句解決方案。每條SQL語句都是3行代碼(而不是一行代碼),並且涉及一個可能出錯的邏輯語句(cyclomatic complexity將通過屋頂)。根據我的經驗,較少的代碼幾乎總是更好......

相關問題