如何設計參數表及其消費者？

Question

我被懷疑爲如何設計參數表很長一段時間......

1. 你認爲這是一個不好的做法讓HTML包含一個Web應用程序的PKS？我認爲是的，我建議使用guids代替pks。
2. 您是否知道與參數表te設計相關的任何模式？通常我會在某些數據庫設計中找到一種參數數據表（即性別表，國家表等）。我更喜歡只有一個包含所有參數的表格和一個帶有鍵的列來從上層引用它們。
3. 您如何看待與參數表具有相同信息的源文件？我已經看到一些項目有與每個參數相關的pk的源代碼...這是一個好習慣嗎？
4. 您認爲創建緩存方案來保存參數數據是相關的嗎？

謝謝！

注：這個問題延伸this。

Answer 1

很難理解你在描述什麼而不看到一個例子。但是，這聽起來像是你在談論數據庫設計反模式，通常稱爲一個真正的查找表。

CREATE TABLE Parameters (
    key VARCHAR(20) PRIMARY KEY, 
    value VARCHAR(255) NOT NULL, 
); 

這種設計的問題包括：

• 你不能使用最適合的SQL數據類型，因爲value列必須適應整數，日期，字符串 - 所有值所有可能的參數類型。

• 您不能使用約束來限制給定參數類型的值。例如，您可能需要一個CHECK約束，以確保郵政編碼符合特定模式。但是你不能，因爲那麼所有類型的所有參數都必須符合相同的模式。

• 您不能將此表用作查找表來約束其他表。例如，如果您希望另一個表中的country列引用國家/地區列表並且不允許其他值。通過將所有查找數據存儲在同一列中，您的country列可以引用任何參數類型的任何值。沒有國家'M'或'F'，但您的數據庫將允許country引用它。

• 不能無論如何創建一個真正FOREIGN KEY約束，除非Parameters.value列有一個UNIQUE約束它，它不能因爲'M'可能是「陽」或「中等恤尺寸」，因此出現兩次在參數表中。

• 由於無法強制表中包含具有某個主鍵的行，因此無法保證給定鍵存在。這是NOT NULL適用於常規數據庫設計，其中參數屬於列而不是行。

• 表可以變大，使之成爲低效的查找，在一小部分屬於正確的值。您的應用程序配置參數列表存儲在國家和郵政編碼等列表中。

儘管理查德哈里森wrote in his answer to your other question，他是錯的。 OTLT是一個糟糕的設計，你會後悔使用它。

又見OTLT and EAV: the two big design mistakes all beginners make

---

關於你提到的具體問題：

你認爲這是一個不好的做法讓HTML包含一個Web應用程序的PKS？我認爲是的，我建議使用guids代替pks。

有關在Web應用程序的用戶可見層顯示pks的最常見警告是，它可以爲攻擊者提供有關如何處理部分數據的信息。這聽起來像你仍然顯示在你的web應用程序的PK值，但你只是交易的GUID爲整數。我不明白這是更好的。要清楚的是，如果你的代碼允許用戶通過知道PK值來做非法的事情，那麼如果用戶知道映射到PK值的代理值，它也將允許相同的非法行爲。您尚未使用代理值添加任何保護。

然後有必要「鋌而走險」？可以做些什麼呢？

Defensive programming.不要假設用戶只會點擊爲他們提供的鏈接，他們可以編輯指定某些其他的PK值，並提交該鏈接。攻擊者擅長這類事情。

例如：

http://www.example.com/change-password.php?account_id=12345&new-password=xyzzy 

你的PHP腳本應該檢查當前用戶的會話登錄到具有特權更改密碼的帳戶12345不要只是假設一個帳戶，這沒關係，因爲Web應用程序不會向用戶顯示一個鏈接來執行他們沒有權限執行的操作。即使應用程序是正確的，攻擊者也可以將值更改爲任何他們想要的值，然後提交該值。

您必須在您的應用程序編寫代碼來檢查用戶有權限使用他們請求數據，假設他們可以要求，即使他們沒有權限看到它的數據。如果你能做到這一點，你可以降低暴露pk值的風險。

更新：隱藏的PK值是security by obscurity，這不是一個有效的安全策略。您的代碼需要檢查用戶是否有權查看或更改該PK的記錄。如果你這樣做正確，攻擊者應該得到，如果他們試圖做一些事情，他們不應該「拒絕訪問」錯誤。

如果您有程序員犯錯誤，那麼將您的應用程序設置爲假定用戶沒有權限，程序員需要編寫代碼以在每種類型的操作之前建立授權。

另外，使用代碼測試來驗證用戶是否只能在具有正確特權的情況下調用給定任務，而非特權用戶無法調用該任務並且他們收到相應的錯誤消息。要求程序員爲他們接觸的任何功能編寫測試。

我更喜歡只有一個表的所有參數和一列用鍵從上層引用它們。

號OTLT是一個不好的設計。往上看。

您如何看待與參數表具有相同信息的源文件？我看到一些項目有源代碼，每個pk都與一個參數有關......這是一個很好的做法嗎？

號在數據庫中存儲的參數的意義在於讓你可以通過訪問數據庫進行更新，他們會自動採取在使用該數據的其他頁面的效果。如果您不得不更新代碼以使用新值，那麼將參數存儲在數據庫中沒有任何優勢。如果這是真的，你可能也只有存儲值中的代碼。

關於具有參數數據的源代碼：如何從客戶端代碼引用特定的prm？假設我有在經營業務層關於使用PRM數據來工作中的性別一些邏輯？如何與這兩個數據（我用來創建常數表）？我想我至少需要一鍵硬編碼在BL ...

我猜你使用的一切代理鍵...

你知道how to use JOINs in SQL？您可以將您的表加入查找表並搜索值而不是代理鍵。

SELECT ... FROM People JOIN Genders USING (gender_id) WHERE gender = 'M' 

對於查找表，我喜歡用自然鍵。然後你就可以在價值'M'，而不是該值的代理鍵進行搜索。

SELECT ... FROM People WHERE gender = 'M' 

你是否認爲這是有關創建緩存方案，以保持參數數據？

是。參數數據可能很少發生變化，並且您的應用可以通過減少應用用於獲取它們的查詢次數而獲益。更新值時，使緩存中的相應條目無效。