我有一个有趣的设计问题。我正在设计项目的安全性方面，以允许我们针对不同的成本获得不同版本的程序，并允许管理员类型的用户向其他用户授予或拒绝部分程序的访问权限。它将转到基于网络并托管在我们的服务器上。将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