0

我有一个有趣的设计问题。我正在设计我们项目的安全方面，以允许我们以不同的成本拥有不同版本的程序，并允许经理类型的用户授予或拒绝其他用户访问程序的某些部分。它基于网络并托管在我们的服务器上。

我为每个“资源”或屏幕使用简单的允许或拒绝选项。

我们将拥有大量资源，用户将能够设置许多不同的组来将用户放入以控制访问。每个用户只能属于一个组。

我有两种方法可以解决这个问题，并且很好奇在性能方面哪种方法更适合 SQL 服务器。

选项 A 访问表中存在条目意味着允许访问。这将不需要数据库中的列来存储信息。如果没有返回结果，则拒绝访问。

我认为这将意味着一个较小的表，但查询会搜索整个表以确定没有匹配项吗？

选项 B 控制允许/拒绝的数据库中包含一个位列。这将意味着总能找到一个结果，并形成一个更大的表。

想法？

4

4 回答 4

4

如果它只是允许/拒绝，那么用户和资源之间的简单链接表就可以正常工作。如果在链接表中存在与 User-Resource 相关的条目，则允许访问。

UserResources
-------------
UserId FK->Users
ResourceId FK->Resources

sql会是这样的

if exists (select 1 from UserResources 
where UserId = @uid and ResourceId=@rid)
set @allow=1;

使用（UserId 和 ResourceId）上的聚集索引，即使有数百万条记录，查询也会非常快。

于 2008-08-22T20:41:25.190 回答
1

我会投票给选项 B。如果您选择选项 A 并假设如果用户存在，他们可以进入，那么您最终会遇到一个问题，即您想要拒绝访问用户，而不删除用户记录。

在很多情况下，您希望锁定用户，但又不想完全销毁他们的帐户。一个这样的例子（不一定与您的用例相关联）是当您未能付款时，他们会切断您的帐户，直到您再次开始付款。他们不想删除记录，因为他们仍然希望在您再次付款时启用它，而不是从头开始重新创建帐户并丢失所有用户历史记录。

于 2008-08-22T20:33:56.567 回答
0

B. 它可以更好地检查数据是否完整（例如，当您添加允许/拒绝功能时）。

此外，表大小应该只考虑您知道将包含许多记录（如 100,000+）的表。您甚至花时间在这个问题中输入表大小的考虑已经花费了比它所需要的额外硬盘空间更多的成本。

于 2008-08-22T20:35:30.510 回答
0

方法 A，但除了您的隐式拒绝之外，我还将包括一个显式拒绝。我会做一些用例来确保你的最终逻辑有效，但这里有一些例子。

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.

我相信您的方法 users1 将被允许。

于 2008-08-22T21:02:17.870 回答