2011-12-03 86 views
2

我有一個應用程序,它看起來好像存儲一些硬編碼在應用程序代碼中的記錄而不是數據庫中的條目,並且能夠在查看記錄時將兩個記錄合併爲一個通用結果集。這種方法有沒有陷阱?首先,除了當應用程序開發者想要的時候,它似乎更容易強制記錄從不被編輯/刪除。其次,在安裝第三方模塊等情況下,可以從配置中讀取記錄,而不是在db中執行插入操作(包含相關的維護問題)。在應用程序中存儲一些記錄,並在數據庫中存儲一些記錄?

一些常見的例子:

         In the application  In the database 
----------------------------------- ------------------  ---------------------- 
customers        (none)     all customers 
HTML templates       default templates   user-defined templates 
'control panel' interface languages default language   additional languages 
Online shop payment processors   all payment processors (none) 

所以,我想我有根據情況三個選項:

  1. 數據庫中的所有記錄
  2. 在應用程序中的一些記錄,一些記錄在數據庫中
  3. 應用程序中的所有記錄

它似乎有兩種方法來實現:

  1. 所有記錄在數據庫中:
    • A柱可以被標記爲「可編輯」或「鎖定」
    • 負的ID可能代表鎖定的價值觀和積極的ID可以代表編輯
    • 奇數編號代表鎖定,甚至標識表示可編輯...
  2. 一些[R生活在應用程序(作爲變量,數組或對象...)

有沒有任何標準的方法來處理這種情況?我錯過了一些非常明顯的解決方案?

我正在使用MySQL和PHP,如果這改變了你的答案!

回答

0

一般情況下,任何時候如果你想包括東西是硬編碼到工作流程你進行數據庫查詢的,沒有任何加盟需要發生。您只需簡單處理硬編碼數據以及從數據庫中提取的數據。如果我們正在討論形成對象的信息,那麼在應用程序中創建對象時尤其如此。例如,我可以看到,如果您希望在應用程序中始終有開發用戶,這會很有用。您可以讓此用戶在應用程序中進行硬編碼,並且每當您查詢數據庫時(例如登錄用戶時),都會在查詢數據庫之前檢查硬編碼的用戶值。

例如:

// You would place this on the login page 
$DevUser = new User(info); 
$_SESSION['DevUser'] = $DevUser; 

// This would go in the user authentication logic 
if($_SESSION['DevUser']->GetValue(Username) == $GivenUName && $_SESSION['DevUser']->GetValue(PassHash) == $GivenPassHash) 
{ 
    // log in user 
} 
else 
{ 
    // query for user that matches given username and password hash 
} 

這說明怎麼會有不需要是任何特殊或棘手的數據庫的東西怎麼回事。如果您不加以考慮,那麼在數據庫驅動的工作流程中包含的硬編碼變量非常簡單。

可能會出現這樣的情況,您可能有很多硬編碼的變量/對象,或者您可能想對這兩組信息執行大塊邏輯。在這種情況下,擁有一個包含硬編碼信息的數組可能是有益的,然後您可以將查詢的信息添加到該數組,然後再對其執行任何邏輯。

在支付處理器的情況下,我假定您指的是使用不同服務(如PayPal或信用卡或其他服務)的在線支付。這對於每種付款方式都具有單獨功能的付款類最有意義。這樣你可以調用客戶選擇的任何一種方法。我想不出你想要處理這個問題的其他方式。如果您可能正在討論可爲您的客戶提供的付款選項,那麼您的付款頁面上就會有這樣的硬編碼。

希望這會有所幫助。請記住,不要讓它比它需要的更復雜。

+0

感謝您的輸入! – boatingcow

1

「在應用程序中」,你是指這些記錄存在於文件系統中,可供應用程序訪問嗎?

這一切都取決於你正在建設的應用程序。有幾件事情需要考慮,特別是當涉及到代碼複雜性和性能時。雖然我沒有足夠的關於您的項目的信息來建議具體細節,但需要注意以下幾點:

有兩個可能的存儲庫可以提高代碼的複雜性。這意味着可讀性將下降,奇怪的錯誤將開始出現,難以追蹤。在大多數情況下,使用最簡單的解決方案可能有用,這對您最有利。如果你看看大的PHP/MySQL軟件包,你會發現即使代碼本身有很多默認值,數據幾乎全部來自數據庫。當您無法擺脫最簡單的解決方案(即將所有文件存儲在文件中)時,這可能是一個合理的策略。

沉重的數據庫參與的一大缺點是性能。您應該一定要跟蹤應用程序中任何典型代碼路徑的所有數據庫調用。如果您嚴重依賴大量查詢,則必須採用大量緩存。跟蹤發生的所有事情,並牢記計算機爲了滿足請求而必須做的事情。讓計算機的任務儘可能簡單是你的工作。

如果您存儲在數據庫中的模板,再大的性能損失將是缺乏操作碼複用和緩存。普通的Web主機環境編譯一個PHP文件一次,然後保持它的字節碼版本一段時間。這節省了後續的重新編譯並大大加快了執行速度。但是,如果您將PHP模板代碼填充到eval()語句中,則每次調用該代碼時都必須重新編譯此代碼。

另外,如果你使用的eval()以這種方式,你允許用戶編輯模板,你必須確保這些用戶的信任 - 因爲他們將有機會獲得整個PHP環境。如果您正在使用其他路線並使用模板引擎,則可能會有更大的性能問題(但不是安全問題)。無論如何,請儘可能考慮緩存模板輸出。

關於鎖定機制:看來你在這裏引入一個大的建築問題,因爲你現在必須使每個存儲庫(文件DB)瞭解記錄禁地到另一個。我建議你完全重新考慮這個方法,但是如果你必須的話,我強烈建議你用一個單獨的列標記記錄(基於ID的東西聽起來像是一場噩夢)。標準的方法是在DB中保留經典的DB形狀的東西(這些將是用戶帳戶和其他東西,很適合放入表格中),並將配置,所有代碼和模板事物保存在文件系統中。

+0

謝謝Udo。我已經編輯了文本,以便「在應用程序中」變成「硬編碼」 - 換句話說,不是從數據庫的行中檢索數組(或對象),而是將數組(或對象)寫入代碼。不是「默認」值 - 它們用於形成對象的藍圖 - 而是具有自己特定值的實際對象。 – boatingcow

+0

+1表示可維護性問題。 – cmbuckley

1

我認爲在應用程序中保留一些固定值硬編碼可能是解決此問題的好方法。在大多數情況下,它甚至會減少數據庫服務器上的負載,因爲有些不是所有的值都必須通過SQL檢索。

但有些時候它可能會導致性能問題,主要是如果你要加入與您的硬編碼值的數據庫來值。在這種情況下,將所有值存儲在數據庫中可能會有更好的性能,因爲所有值都可以由數據庫服務器進行優化和處理,而不是從SQL查詢中獲取所有值並在代碼中手動加入它們。

爲了應對這種情況,你可以存儲值的數據庫,但插入和更新必須只是你的維護處理或升級程序。如果您更關心不要修改數據,則可以設置一個維護例程來檢查數據庫中的值是否與代碼相同。在這種情況下,這個數據庫表非常像硬編碼值的「緩存」。並且,當您不需要將固定值與數據庫值結合使用時,仍然可以從代碼中獲取它們,從而避免不必要的SQL查詢(因爲您確定它們的值相同)。

相關問題