外键应该放入哪张表,怎样设外键更合理?

Question

[User]
UserID  //PK
UserName
Password
RoleID  //FK[Role]
RoleID  //PK
Description[Grant]
GrantID  //PK
AddUser
MdfUser
DelUser请问我这里的GrantID是应该放入[User]表呢,还是放入[Role]表,还是二处都放呢?

Answer 1

[Grant]
GrantID //PK
UserID
操作类型 //AddUser，MdfUser，DelUser

Answer 2

我也觉得应该是放在Grant表里。

Answer 3

看一下ORACLE权限相关表结构你就清楚了

Answer 4

GrantID应该放入[User]表,我觉的.

Answer 5

不对,还是一楼说的对,UserID 应该放到Grant表里,跟User的UserID 对应

Answer 6

//看了大家的回复,我的设想改变了,特别是失踪的月亮的回复给了我启发,
//那就是可以存在二种权限分配方式:
[User]
UserID  //PK
UserName
Password
RoleID  //FK
GrantGroupID  //FK  //按组权限,引用[GrantGroup]表   [Role]
RoleID  //PK
RolePower //Admin,Master,User
Description//第一种:按组方式分配权限
//我最初的方式,通过分组为三种角色制定三种权限
//Y(Yes)代表具备,N(No)则相反,当然此处你也可以用1和0代替.
[GrantGroup]
GrantGroupID  //PK    1    2    3
AddAdmin              Y    N    N
MdfAdmin              Y    N    N
DelAdmin              Y    N    N
AddMaster             Y    N    N
MdfMaster             Y    N    N
DelMaster             Y    N    N
AddUser               Y    Y    N
MdfUser               Y    Y    N
DelUser               Y    Y    N
AddTopic              Y    Y    Y
MdfTopic              Y    Y    Y
DelTopic              Y    Y    Y
ChkToPic              Y    Y    N        //第二种:自定义方式分配权限
//失踪的月亮的方式,可以更细化的对每一个用户分配权限
GrantCustom]
GrantCustomID  //PK
UserID  //FK   //用于存放用户标识符,可以有N种分配方式,引用[User]表
AddAdmin
MdfAdmin
DelAdmin
AddMaster
MdfMaster
DelMaster
AddUser
MdfUser
DelUser
AddTopic
MdfTopic
DelTopic
ChkToPic

Answer 7

放在[User]表中.
原因:
     用面向对象的观点来看:Grant和Role是两个属性类, User才是真正的实例类. 换言之, 在实际应用中, 前两者都是为User
服务的, 那么User与 Grant和Role 之间是组合关系, 也就是说 User包含 Grant和Role.     再从数据扩展来看:假设我们把UserID放在Grant中,那意味着什么?那表示如果有一个Grant, 那么它要么对应一个(且不同的)
UserID, 要么就不合理(因为该Grant定义了但没有授予给任何User).举个例子.假设存在一个Grant名为G, 现在要授权给A集团下
B1公司的UserID为100的C员工, 这是没问题的.但是:现在如果又要给B2公司的UserID为100的D员工授予同样的权限, 该怎么做?依照这种设计, 无非有两种解决办法:1, Grant表中再增加集团(Group)表和公司(Company)表的Reference Key
                               2, 对集团员工统一编号
第一种方法:数据冗余; 第二种方法基本上是不现实的, 不合理的.见过员工直接对集团而不是对公司的设计吗?而把GrantID放在User表中就不会存在这些问题.当然也可能存在一个用户拥用一个以上的权限如果处理的问题.
但由于把Grant单独放开, 它是可以自行扩展而不影响其他数据的. 比如某个用户E需要拥有A和B两种权限,
这时完全可以在Grant中定制一个AB权限再授予E.同时也不会影响其它的用户.