【问题标题】:Choosing a Model for Storing Complex Dynamic User Profiles/Settings选择用于存储复杂动态用户配置文件/设置的模型
【发布时间】:2011-08-24 01:58:29
【问题描述】:

这是布局

  • 我正在开发一个带有 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 表中的每个设置附加一个 name=value 对记录并使用 UserID 外键代替?
  4. 等等等等……

我的理想答案:

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

【问题讨论】:

  • 听起来你可能在看东西。每个产品都有一个唯一的所有者而不是用户拥有一个产品列表是否更有意义?如果关系是多对多的,那么您将需要一个表来处理映射。不要害怕,桌子是你的朋友。
  • 这个问题似乎很广泛。您能描述一下您在第一个项目符号中设想的四个表格吗?
  • @Aaron:我宁愿有新的想法,也不愿重复我的烂摊子。我对内置的 ASP.NET 功能最感兴趣,因为它对我来说是新的,而且我发现关于它的实现的有用文档很少。谢谢:) ...和user92546:确实是多对多。
  • 我的问题是基于此:对于任何人(或至少对我而言)提出任何新鲜想法,我需要对基本要求有一些的了解。你在谈论角色和产品,但对我来说非常抽象。像@Cade 一样,我倾向于在数据库中进行建模,而不是在 ASP.NET 中,但除了通用立场之外,我真的无法提供任何东西,除非我对我们实际谈论的内容有一个稍微低层次的想法。你能至少说出你到达的四张桌子吗?
  • @Aaron:按要求添加。我期待您的想法,并感谢您愿意提供帮助:)

标签: asp.net sql-server web-applications asp.net-membership asp.net-profiles


【解决方案1】:

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

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

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

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-04-09
    • 1970-01-01
    • 2020-05-19
    • 1970-01-01
    相关资源
    最近更新 更多