经典的数据库设计贴吧

我要设计一个数据库要求：

用户至少要有5种，对每个设备的操作有20种，设备至少要有15个。后期还有可能添加设备或是每个设备的操作，或是用户种类

我设计如下：
用户表
User_id     User_name    User_(其他属性，如邮箱，地址，联系方式等等)
1           User1           张三@qq.com
2           User2           李四@qq.com
...

设备表
Equip_id   Equip_name   Equip_description
1          Equip1       用于监视的设备
2          Equip2       用于操作的设备
...
权限表
Right_id   Right_name   Right_description
1          a            操作1
2          b            操作2
...

用户设备权限表
ID         User_name    Equip_name       Right
1          User1        Equip1           abc(即拥有a，b，c三种权限)
2          User1        Equip2           ab
3          User2        Equip1           a
4          User2        Equip2           b
...
感觉最后一个表会很复杂。不知道遇到这种情况的话要怎么做呢。。。期待~~

superdullwolf superdullwolf 等级： 结帖率：98.97% 3	#3 得分：0 回复于： 2009-03-05 12:28:48 顺便，每次设计数据库的时候默念3个泛式： 1NF:原子不可分性,就是每个字段不可以拆分，比如1,2,3或者你的abc这样的设计就违反了。 需要把字段拆成多行记录 2NF:主键关联性，每个表所有字段必须依赖于主键。 3NF:只和主键关联性，表和表之间只依靠主键关联，表的其他字段之间不互相依赖。 以上3条，我是用自己的语言整理的，希望你也用自己的话来整理。 我一般浓缩成3个词： 不可分，关联，非关联 或者 原子，依赖，不依赖
	2012年中国软件行业技术人员薪资大调查 对我有用[1] 丢个板砖[0] 引用 | 举报 | 管理 | TOP

账号:superdullwolf 昵称:superdullwolf 关注 博客空间 最新帖子: 重新申请算法版大版主 如何去掉APACHE对于URL大小写匹... php中oauth开发包，如何使用，... 更多 >> superdullwolf superdullwolf 等级： 结帖率：98.97% 3

#1 得分：0 回复于： 2009-03-05 12:22:53 最后一个表不是复杂的问题，是违背了设计泛式1NF,第一原则：原子不可分性。 多对多的关系，需要一个中间表，防止出现需要拆分字符串abc这种现象。 还有，外键一定要用数字Id,不要User_name  ，Equip_name 这样使用varchar类型做关联， 因为会产生歧义，可能同时有两个同名的人或设备。 这是数据库设计的第3泛式3NF，唯一关联性（只和主键关联） 所以你最后一个表应该这样设计,前几个表都没问题 用户设备权限表 ，这个表的ID用途不大，主要是3个外键起作用。 ID        User_Id    Equip_Id     RightId  xx          1           1           1 xx          1           1           2 xx          1           1           3 这样三条记录，就代表abc，即拥有a，b，c三种权限

IBM 邀您分享国内外迁移Power案例 对我有用[1] 丢个板砖[0] 引用 | 举报 | 编辑 删除 管理 | TOP

账号:superdullwolf 昵称:superdullwolf 关注 博客空间 最新帖子: 重新申请算法版大版主 如何去掉APACHE对于URL大小写匹... php中oauth开发包，如何使用，... 更多 >> superdullwolf superdullwolf 等级： 结帖率：98.97% 3	#4 得分：0 回复于： 2009-03-05 12:39:21 我工作12年，其中权限系统几乎是每个大中型项目必须的，所以我已经驾轻就熟，已经不把它当回事了。 我设计权限的惯例是： 1，用户表（字典表） 2，角色表（字典表） 3，拥护角色表（关系表） 4，功能表（字典表） 5，角色功能表（关系表） 这里边包括2个关系表，如果简单的系统可以不分角色 1，用户表（字典表） 2，功能表（字典表） 3，用户功能表（关系表） 但是一般系统都是比较复杂，而且加一个角色可以把用户分组，方便授权操作。 因为用户是大量的，功能是大量的，所以把用户利用角色来分组， 授权的界面就是给用户加到某一组或多组（赋予角色），而角色和权限早就规划好了。 就简单多了。 如果再复杂的系统，就把功能也分组或者树状功能菜单。 所谓权限就是控制用户看到哪个菜单（功能）。
	对我有用[2] 丢个板砖[0] 引用 | 举报 | 编辑 删除 管理 | TOP

superdullwolf superdullwolf 等级： 结帖率：98.97% 3	#5 得分：0 回复于： 2009-03-05 12:47:19 数据库里的表，你可以分成2大种。 1，字典表（有一个主键） 2，关系表（有2个以上的数字外键） 有些表具有2中特点，那么有时候他是作为字典表使用，有时候是作为关系表使用的。 比如定单，就是记录用户和产品的关系的关系表，同时定单也是有编号和其他字段的字典表。 当查用户买了什么产品的时候，他是关系表。 当根据单号来查看其他字段的时候，他是字典表。 这样你可以迅速的设计或读懂别人的设计。 也可以马上看出设计的问题。
	对我有用[0] 丢个板砖[0] 引用 | 举报 | 编辑 删除 管理 | TOP

xie0706 xie0706 等级： 结帖率：100%	#9 得分：0 回复于： 2009-03-06 13:22:19 学习了
	对我有用[0] 丢个板砖[0] 引用 | 举报 | 编辑 删除 管理 | TOP

superdullwolf superdullwolf 等级： 结帖率：98.97% 3	#10 得分：0 回复于： 2009-03-06 14:12:42 多对多的关系，习惯就不觉得复杂了。 ID        User_Id    Equip_Id    RightId  xx          1          1          1  xx          1          1          2  xx          1          1          3  通过3行记录，达到你原先设计的一行记录的目的 ID        User_name    Equip_name      Right  1          User1        Equip1          abc(即拥有a，b，c三种权限)  在具体编程时候，符合规范的设计，会带来很大方便。 权限设计这个算是简单的了。 我还整理了一些更复杂的，见下文。
	对我有用[0] 丢个板砖[0] 引用 | 举报 | 编辑 删除 管理 | TOP

superdullwolf superdullwolf 等级： 结帖率：98.97%

#11 得分：0 回复于： 2009-03-06 14:12:57 数据库设计多对多关系的几种形态  前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少， 而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。  按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者select * from 主表 where id in (select 主表id from 关系表)  1，角色任命型  特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。  界面特点：显示主表，用checkbox或多选select设置多选关系。  例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立， 关系表的两个外键具有联合主键性质。  增加关系：如果没有组合纪录，insert之。  删除关系：如果有组合纪录，删除之。  2，集合分组型  特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表， 可能都很大不固定。  界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。  例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。 文章标签（文章表-关系表-标签表）  增加关系：同版主任命型。  删除关系：同版主任命型。  3，明细帐型  特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。  界面特点：显示关系表，用radio或下拉设置单选关系。  例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。  增加关系：不管有没有组合纪录，insert之，纪录时间。  删除关系：根据关系表PK删除。  4，评论回复型  特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。  界面特点：回复文本框。  例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。  增加关系：不管有没有组合纪录，insert之，纪录时间和文字。  删除关系：根据关系表（回复表）PK删除。  5，站内短信型  特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息） 或者其他标记位来表示文字已读状态时间等。  界面特点：回复文本框。  例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。  增加关系：不管有没有组合纪录，insert之，纪录时间和文字。  删除关系：根据关系表（回复表）PK删除。  6，用户好友型  特点：主副表是同一个，同集合分组型，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。  界面特点：同集合分组型，显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。  例如：下载站点的文件，（文件表-关系表-文件表）可以被软件工具打开，软件工具本身也是一种文件，可以被下载。 用户的好友，也是用户（用户表-好友关系表-用户表）  增加关系：同版主任命型。  删除关系：同版主任命型。  7，未知属性型  特点：在设计初期，主表的某些字段类型和名称是不确定的时候，关系表实际上是主表的可扩展字段，  一个[主表]（ID），  一个[属性名称表]（属性ID.属性名称)，  一个[属性值表]，包括3个字段：        属性值(属性Value varchar(500))        主表ID        属性ID  这样可以作到最小冗余度。  （和常见的多对多关系不同的是：值统一用varchar来存储，因为这类型的值一般不会用来计算）。  比如：  军队的数据库设计中有种物资叫做“战缴物资”，就是打仗的时候缴获的，军队自己都不知道这些物资有什么属性。  比如缴获的化学品有化学名，通用名，是否有辐射，计量单位，包装规格，数量等等，或者不是化学品是其他任何未知的东西。  这样东西就可以  某奇怪东西.属性集合["某某奇怪属性名"]="某某奇怪值"；   某变态东西.属性集合["某某变态属性名"]="某某变态值"；   这样存储。  再比如：  手机型号有几千种，除了共同属性外还有不同属性有几百个，属性名和值类型都不一样，有的手机有这属性，有的没有。  对于这样的“多态”，我们就采用上面的设计结构。  其效果相当于：  某奇怪手机.属性集合["某某奇怪属性名"]="某某奇怪值"；  某变态手机.属性集合["某某变态属性名"]="某某变态值"；  界面特点：设置主表一行纪录的属性时候，要列出所有可能的属性名称，每个对应一个文本框。

对我有用[0] 丢个板砖[0] 引用 | 举报 | 编辑 删除 管理 | TOP