0

这是布局：

  • 我正在开发一个带有 SQL Server 数据库的内部 ASP.NET Web 应用程序（在 VB.NET 中）。
  • 由于我的用户完全是内部用户，因此我使用“Windows”方法进行自动身份验证。
  • 我有四个用户角色，每个角色都有自己非常独特的动态设置集。
  • 奖励：每个用户可能有多个角色，因此有多个配置文件。

根据我的广泛研究，我确定了以下两种存储用户配置文件设置的方法（这两种方法都会提示问题“如何？”），但我不确定哪种方法最好（如果有的话）：

  • 在数据库中存储配置文件和相关设置（使用什么结构？从初步映射中，我创建了至少四个表，这些表开始变得非常难以管理和维护）
  • 使用内置的 ASP.NET Membership & Profile 对象? （我似乎找不到一个很好的教程。这种方法还需要数据库支持吗？再次，使用什么表结构？） -我对这个可能的解决方案最感兴趣

例子：

我最复杂的用户组需要能够存储与用户关联的所有（用户选择的）产品的配置文件。假设我是一名产品经理，我希望我的帐户向我展示我选择的所有我负责的产品。显然，我角色的每个成员都有不同的产品和不同的数量等。也许用户页面设置（例如搜索、排序、订单默认值等）可以存储在通用表中，并参考辅助设置表对于可以通过可以充当某种“外键”的特殊记录链接到的奇怪的东西。

根据要求，我对餐桌计划的一个想法：

    Users (ID, Username, RoleID)
    Roles (ID, RoleName, Description) --Lookup Table
    Settings (ID, Name, Value)
    UserSettings (ID, UserID, SettingID) --Junction Table

那么问题就来了：

  1. 我什么时候应该使用行与列？
  2. 如果我为每个设置使用一列，我可以定义数据类型，但列数可能会失控。另一方面，如果我对每个设置使用一行，它会更有意义，但我会失去对设置的数据类型的控制。
  3. 我是否应该省略 UserSettings 表，而只为 Settings 表中的每个设置附加一个名称=值对记录，并使用 UserID 外键代替？
  4. 等等等等……

我的理想答案：

如您所见，我有很多问题，但似乎没有找到什么帮助。如果有人可以简单地为我分解它，我会喜欢它。请告诉我您的专业建议和一些关于如何实现它的超级简单技巧（即使用哪些 ASP.NET对象，以及所述对象如何提供管理我的复杂配置文件的机制）

4

1 回答 1

1

我认为这几乎肯定需要在数据库中建模。

与用户相关的产品实际上并不是基于角色的东西——因此必须在很大程度上独立于角色，即使你说只有经理才会有这种关系。只有角色中的用户才会有这种链接，但这是一种高级限制，您可能会在应用程序级别或某些更高级别的约束中强制执行 - 而不是使用外键 - 除非您有依赖于用户和角色的链接。

那么作为经理的用户可能有某些产品，但作为推销员，可能有不同的产品。那么这个角色也将在链接表中。有时链接表行确实具有关于链接的属性，而不仅仅是链接本身（通常是有效日期和活动/禁用标志等）。

于 2011-08-24T03:23:23.047 回答