高分求多用户站点用户数据库设计方案

[风声3]

这帖考虑了一下还是决定发在ASP.NET版块。我是针对ASP.NET站点设计数据库的。

我先解释我所说的多用户站点概念：
拥有多种类型用户的站点，比如，人才网站通常有，个人会员、企业会员；学校OA有学生、教师；我通常还把管理团队也归为一种类型。

按我以前的思维，每一种类型对应一个数据表，分别对应不同的登陆入口。学习ASP.NET以来，发现很多网站都是统一入口，然后根据不同的角色完成不同类型用户的功能。但我不知道大家的数据库是不是也是统一设计，然后设计角色表。

也比如人才网，我了解的有于下两种方案，想知道大家是怎么做的：
方案一：统一设计用户（登陆）数据表，然后设计免费个人、收费个人，免费企业，收费企业，运营管理，超级管理等角色。
疑问：这多种角色逻辑上并不并列，许多属性处理起来会不会别扭。

方案二：设计三套用户角色系统：一、设计个人数据表，设计免费个人、收费个人角色；二、设计企业数据表，设计免费企业、收费企业角色；三、设计管理团队数据表，设计运营管理、超级管理角色。
疑问：逻辑上比较清晰，看起来复杂，而且ASP.NET不大这么做。

[jsyxo]

一个用户表,表里有个用户类型的字段,用这个字段来区别各种类型的用户,然后在用户类型表中设置对应用户类型的权限

[风声3]

楼上大概与我所说的第一种方案类似吧

[风声3]

这帖怎么这么没潜力？涉及商业机密了？

[以专业开发人员为伍]

我没有看懂你说的“设计角色表”是什么意思？如果是用户的角色，那么显然应该先设计角色，而后设计用户。而你的依赖关系看上去不像是用户与角色的关系，倒像是一般用户与具体用户的关系。

你举出几个有属性、操作流程的对象实例来看看？！

[zhangshg2008]

学习一下

[以专业开发人员为伍]

你的方案一和方案二我看上去可以说基本没有区别。方案一的疑问在方案二仍然存在，结构原理和应用功能一模一样，只不过多加了一层分解（有人喜欢1分为3，有人喜欢直接1分为9），如果说“更清楚”估计也只是一种自我安慰。

问题就是你的角色到底该是什么意思？

比如你说的“人才网站通常有，个人会员、企业会员；学校OA有学生、教师”，这既可以实现为一般用户与具体用户的关系，也可以实现为用户与角色的关系。

以那些“范例”的风格，会喜欢把类型拆得七零八落不论什么需求都用角色以及更零散的方式实现，这就像垃圾快餐食品能够比地域性很强的传统食品卖的更多。

如果你设计好了再动手，那么对于一个一般的“人才网站”或者“学校OA”来说完全可以任选一种方法。

[风声3]

闲着没事顶一下

[hertcloud]

基于角色的 用户系统中

可以使用 唯一一张 用户表 保存 用户基础信息, 对于 不同的类别可以拓展不同类别的 特定信息表.

也可以为不同的类别 定义不同的用户表 , 但是 这个是不和角色起冲突的. 角色系统 只是用于用户访问权限的控制.

[hertcloud]

至于 一般 网站 那种 通行证 登录的模式

只是说在 客户端 使用统一的 模式保存 用户登录信息
比如说 统一 cookies 的域 Domain

对于不同的登录 你查询不同的数据表 即可..

[weiyong922]

帮顶

[hy_lihuan]

其实我觉得两种方案都可以阿,主要是看你这几种人所需要记录的属性是否大致相同;
比如:
你学生有班级属性\专业\学分\寝室等属性;
而教师有教的班级\课时\所教的班级等属性;
这样的话还是把它们分开,这样的设计方便你的扩展;或者把姓名性别等统一在一个父表,其他不同的属性分散在子表里面;这样的话你登录就是用一张表,其他的业务处理就是用子表,逻辑结构也很清晰!

[cat_hsfz]

直接用ASP.NET 2.0的Membership和Roles就行了，不同的角色用Roles来区分，没必要开那么多张表。

[luckbird]

一个表专门保存最基本的信息，用户名，密码，EMAIL,提示问题答案，等与业务无关的信息。

另外一张表保存其它信息，由于每个类型的用户信息不同，可以用XML串来记录用户信息，将这个XML串保存在一个字段中，取的时候取出这个XML字符串，根据用户类型不同，进行解析处理，就可以得到和这个用户对应的所有信息了。