語境通過一致性檢查,我的意思是消除肯定不會返回任何內容的查詢。例如:考慮表boxes,其中可用列之一是color CHAR(6);用戶通過與前端的交互發送該字符串'abcdefg'以針對列進行查詢;color然后,后端將SELECT * FROM boxes WHERE color = ?使用上面提到的相同字符串執行類似于 的查詢;至少在我的 PostgreSQL 安裝中,我可以執行這個查詢,即使知道它永遠不會返回任何內容(長度為'abcdefg'7)。目前,前端和后端都會在從數據庫訪問數據之前執行一致性檢查(以避免不必要的調用)。事實上,前端的設計就是為了禁止用戶請求無效的查詢。但假設沒有進行這些檢查,尤其是在后端,這對應用程序有多重要?問題PostgreSQL 如何處理這些查詢,它是否有任何類型的算法在執行此類查詢時立即不返回任何內容?或者不調用數據庫而只向用戶發送類似not found或 的內容會更好嗎invalid request?進一步的背景我們已經清理了從前端接口獲取的所有輸入,因此這不是關于執行這些檢查后獲得的安全性可能帶來的好處/壞處的問題。我們后端使用的語言是 Go,我相信它在定期執行這些檢查(即在大多數 HTTP 請求上)時沒有問題。PS:我知道你可以在 PostgreSQL 中將十六進制轉換為整數,這只是一個假設的問題,我用它來簡化對問題的理解(我希望它能做到)。
1 回答

12345678_0001
TA貢獻1802條經驗 獲得超5個贊
我會在前端或后端執行此類檢查,只要最方便,但不會同時在兩者中執行。第二道防線是數據庫,兩道就足夠了。
在應用程序中找到不正確的數據是一件好事,但不要太過分:如果您在數據庫和應用程序中硬編碼諸如最大字符串長度之類的內容,則必須在兩個地方修改該限制無論何時,代碼冗余都是一件壞事。
仍然理智的東西在很大程度上取決于品味和意見:我認為檢查應用程序中的長度限制而不是依賴數據庫中的錯誤是很好的,但我認為用猜測的復雜邏輯給應用程序增加負擔是值得懷疑的SQL 語句的結果。
重要的是對數據庫中所有重要的一致性檢查進行建模,只要捕獲并妥善處理數據庫錯誤,就不會出現任何問題。除此之外的一切都可以被視為性能調整,并且只有在它提供了明顯的好處時才應該進行。
- 1 回答
- 0 關注
- 123 瀏覽
添加回答
舉報
0/150
提交
取消