2015-06-11 39 views
0

我正在製作一個簡單的Web界面,以允許對數據庫執行查詢(是的,我知道,我知道這是一個非常糟糕的做法,但它是一個只由少數可信任的私人網站使用用戶目前直接使用數據庫管理器來執行這些查詢,因此Web界面只是爲了使流程更加自動化)。將UPDATE轉換爲SELECT

問題是,爲了安全起見,無論何時檢測到UPDATE查詢,我想先執行一條SELECT語句「等同於」更新(保留WHERE子句)以檢索在執行之前會影響多少條記錄更新。

這個想法是用「SELECT * FROM」替換「UPDATE」,並刪除整個「SET」子句而不刪除「WHERE」。
我想更換UPDATE\s*(.*?)\s*SET.*(\s*WHERE\s*.*)SELECT * FROM \1 \2和類似的,但我沒有「WHERE」條款(不常見,但可能)時有麻煩。

編輯:很難解釋爲什麼我需要這樣做,但我知道存儲過程,查詢構建器,事務等等......但對於我的情況,這不是我需要能夠做到。

+0

您需要完整的SQL語法(考慮包含WHERE,SET等的字符串值......) – jarlh

+1

您可以改爲開始事務,執行更新(並捕獲元數據),然後執行回滾。 – Turophile

回答

2

您應該修復您的設計。用戶更新數據庫中的數據沒有任何問題。問題是他們如何他們這樣做。我的強烈建議是將update陳述包裝在存儲過程中。然後只允許通過存儲過程進行更新。

還有爲什麼我喜歡這種方法有幾個主要原因:

  • 我認爲,一個精心設計的API產生更穩定和維護的代碼。
  • 存儲過程控制安全性。
  • 存儲過程允許更好地記錄數據庫中發生的情況。
  • 存儲過程控制用戶可以執行的操作。

在您的情況下,它們提供了另一個優點。由於所有update代碼位於數據庫端,因此您知道更新語句的樣子。因此,您可以決定如何獲得「預先計數」(這是我假設您正在尋找的)。

編輯:

也有在你設計的一個重要缺陷(如你描述它)。數據可能會在updateselect之間變化。如果你使用存儲過程,有辦法解決這個問題。例如,您可以將操作包裝在一個事務中。或者,您使用SELECT來獲取要更新的行,鎖定這些行(取決於數據庫),並僅對這些行執行更新。

+0

其實對於我的用例來說,這不是一個解決方案,因爲這只是一些「奇怪」和混合場景,並且相同的更新查詢可能永遠不會再次執行 – maid450