我有一個有趣的設計問題。我正在設計項目的安全性方面，以允許我們針對不同的成本獲得不同版本的程序，並允許管理員類型的用戶向其他用戶授予或拒絕部分程序的訪問權限。它將轉到基於網絡並託管在我們的服務器上。將SQL表結構爲匹配或不返回結果是更好嗎
我對每個'資源'或屏幕使用簡單的允許或拒絕選項。
我們將擁有大量資源，用戶可以設置許多不同的組來控制訪問。每個用戶只能屬於一個組。
我有兩種方法來記住這一點，並且很好奇，對於SQL服務器來說性能更好。
選項A 訪問表中存在條目意味着訪問是允許的。這不需要數據庫中的列來存儲信息。如果沒有結果返回，則訪問被拒絕。
我認爲這將意味着一個較小的表，但會查詢搜索整個表，以確定沒有匹配？
選項B 控制允許/拒絕的數據庫中包含一個位列。這意味着總會有結果被發現，並且會形成更大的表格。
想法？
如果只是允許/拒絕，那麼用戶和資源之間的簡單鏈接表就可以正常工作。如果在鏈接表中存在鍵入用戶資源的條目，則允許訪問。
UserResources
-------------
UserId FK->Users
ResourceId FK->Resources
和SQL會像
if exists (select 1 from UserResources
where UserId = @uid and [email protected])
set @allow=1;
隨着（用戶名和RESOURCEID）聚簇索引，查詢將是令人眼花繚亂的快速甚至上百萬的記錄。
我會爲選項B投票。如果你選擇A並假設如果用戶存在，他們可以進入，那麼你最終會遇到問題，你想拒絕訪問一個用戶，而不刪除用戶記錄。
會有很多情況下你想鎖定一個用戶，但不想完全摧毀他們的帳戶。一個這樣的例子（不一定與您的用例相關）是您無法支付時，他們切斷了您的賬戶，直到您再次開始付款。他們不想刪除記錄，因爲他們仍然希望在再次付款時啓用它，而不是從頭開始重新創建帳戶，並丟失所有用戶歷史記錄。
B.它可以更好地檢查數據是否完整（例如，添加允許/拒絕功能時）。
此外，表大小應該只是您知道將包含許多記錄（如100,000+以上）的表的考慮事項。你甚至花時間在這個問題中輸入表格大小的代價已經比花費的額外硬盤空間花費更多。
也許我應該提到我對數據庫的打擊比尺寸更感興趣，我只是觀察方法的差異。 我會重新說明這個問題。 – Tilendor 2008-10-10 00:17:59
方法A，但除了隱式deney之外，我還會包括一個明確的拒絕。我會做一些用例來確保你的結束邏輯有效，但這裏有一些例子。
User1 is in group1 and group2.
User2 is in group1
User3 is in group2
Folder1 allows group1 and deny group2.
User1 is denied.
User2 is allowed.
User3 is denied.
我相信你的方法用戶1將被允許。
我忘了提及一個用戶只能屬於一個組。 – Tilendor 2008-10-10 00:18:36
用戶表將與訪問控制表分開，因此添加或刪除訪問權將不會影響用戶的存在。此外，默認情況下，如果沒有結果被發現拒絕訪問，所以不應該可能意外獲得訪問權限。 – Tilendor 2008-10-10 00:17:11