假设我有一个包含用户的表,名为Users
。这些用户都有用户配置文件。这些配置文件存储在名为UserProfiles
的表中。
然后我有一个名为Settings
的表格,用于存储是否应根据用户的个人资料向任何给定用户显示按钮。
现在,在Settings
表中,我有两列,一个键和一个值,值为字符串。
然后,字符串是由;
分隔的所有用户个人资料ID,如下所示:1,4,16,2
从长远来看,我不觉得这是一个可行的解决方案,但我很难弄清楚如何解决这个问题。
一种方法是为按钮设置一个名为' ShowButtonName'然后存储有一个由userprofileid和一个布尔组成的条目,告诉是否应该为该用户配置文件显示该按钮。
任何指针都会有所帮助: - )
编辑:
为了扩展我的问题,这是我目前的设计
- Id / PK
- UserprofileId / FK to Userprofiles.Id
- PinCode
- Username
- CardCode
- RawCode
- PukCode
- Id / PK
- Name
- Value
- Id / PK
- Name
Users
和Userprofiles
具有一对多的关系,因为多个用户可以拥有相同的用户配置文件。
编辑:
我想出了这个主意。
添加一个名为UserprofileSettings
那个表格看起来像这样
- Id / PK
- UserprofileId / FK to Userprofiles.Id
- ShowCleaningBtn / true/false
- ShowUserBtn / true/false
- ShowLogBtn / true/false
- ShowStatuspanel / true/false
这个解决方案对你来说是怎样的?
答案 0 :(得分:2)
SQL有两种设计的数据类型用于保存多个值 - 不像字符串,你只能通过发明更多结构(例如分隔符,转义机制和/或固定宽度)来实现这一点,并强加于在字符串上。当然,SQL Server无法帮助您访问这些“多个”值,因为它不了解您的编码方案。
设计用于保存多个值的两种类型是XML type和表。通常,表是存储多个值的最佳方式,SQL Server中的大多数最佳工具都可以帮助您充分利用表。
现在,关于您是否将数据存储为表中的多个列或多个行,归结为数据的实际使用方式。如果您最终得到具有相同前缀和不同后缀的多个列(反之亦然),则通常表明模型是错误的 - 名称的这些独特部分可能应该是数据,不是元数据。
所以,你提出了模型:
ShowCleaningBtn / true/false
ShowUserBtn / true/false
ShowLogBtn / true/false
ShowStatuspanel / true/false
感觉有些不对劲。我宁愿将按钮 name 作为一列,以及现在存储为true或false的列的适当的其他名称,例如:
UserprofileId / FK to Userprofiles.Id
ControlName
Visible
Enabled
可能存储控件相关状态的其他列。然后它会为CleaningBtn
添加一行,为LogBtn
添加一行,等等。
如果某些控件需要大量设置,则可能会考虑包含这些设置并返回此设置的附加表或稀疏列。或者,您可以考虑使用额外的xml
扩展列来存储此类设置 - 但前提是您不太可能希望直接在SQL中查询此数据。
答案 1 :(得分:0)
您不应将id
存储在字符串中。这对数据库来说是一种糟糕的格式,对于SQL Server来说尤其困难。
每个id
都需要一行,因此表格的列如下:
您可能还有其他列,例如:
除非您正在使用数百万用户/设置组合,否则您不必担心性能(尽管索引可能是您要运行的查询所必需的。)
答案 2 :(得分:0)
听起来像典型的多对多关系,通常用链接表实现。希望你不介意,但我已将你的表设置重命名为Permissions和UserPermissions,这更符合你正在做的事情。表结构将是这样的......
Users
- Id / PK
- UserprofileId / FK to Userprofiles.Id
- PinCode
- Username
- CardCode
- RawCode
- PukCode
Permissions
- Id
- Name
- Type (Class of Permission e.g. Screen, Action. Or finer granularity of ReadAddress, WriteAddress)
UserPermissions
- Id
- UserId
- PermissionId
- Level (Explicitly Granted or denied or null for default)
也不确定您的个人资料是否真的是一个用户只能包含在一个角色中的角色。如果是这种情况,它会简化分配给ProfileId(RoleId)的权限的事情,那么您就不必费心为每个用户维护每个配置文件/角色。
希望这是有道理的。