这是一个创建于 3891 天前的主题，其中的信息可能已经有所发展或是发生改变。
网站的用户分2个群体，一边是teacher，另一边是student。
teacher和student有很多字段是相同的，比如：name, sex, email, password, avatar, check_message_time, create_time。
然后各自也有专属字段：
* teacher：毕业大学、授课方式、类型（在校、在职）
* student：性格、对老师的要求
teacher和student的登陆、注册、找回密码等入口页面是一样的。然后teacher和student之间可以相互私信。
有2种设计方案：
* 方案A：单独的teacher表 + student表
* 方案B：user表保存共有信息，额外的teacher表保存老师专有信息，额外的student表保存学生专有信息。user和teacher是一对一关系，user和student也是一对一关系。
个人感觉方案A有点累赘，而方案B的话又带来了很多join操作。
大家的看法是？或者有更好的设计方案，非常感谢！
teacher和student有很多字段是相同的，比如：name, sex, email, password, avatar, check_message_time, create_time。
然后各自也有专属字段：
* teacher：毕业大学、授课方式、类型（在校、在职）
* student：性格、对老师的要求
teacher和student的登陆、注册、找回密码等入口页面是一样的。然后teacher和student之间可以相互私信。
有2种设计方案：
* 方案A：单独的teacher表 + student表
* 方案B：user表保存共有信息，额外的teacher表保存老师专有信息，额外的student表保存学生专有信息。user和teacher是一对一关系，user和student也是一对一关系。
个人感觉方案A有点累赘，而方案B的话又带来了很多join操作。
大家的看法是？或者有更好的设计方案，非常感谢！
第 1 条附言 · 2014-04-03 13:37:51 +08:00
SQLAlchemy的declarative可以蛮好地解决这种问题，感谢各位！
http://docs.sqlalchemy.org/en/rel_0_9/orm/extensions/declarative.html#inheritance-configuration
http://docs.sqlalchemy.org/en/rel_0_9/orm/extensions/declarative.html#inheritance-configuration
 |
1
jones 2014-04-03 09:00:07 +08:00 via Android  1
以ORM的思维来说肯定是第二种，join一般不用担心，现代的ORM都带有延迟加载和缓存的功能，查询一个user对象其实也就一条普通的select，对象中只持有老师或学生的关联id，调用user的get老师方法的时候，ORM会自动去加载老师的数据，首先查找缓存，没有找到在另外发送一条SELECT，然后把返回的老师数据放入缓存中，当然这只是理想情况下，
|
 |
3
min 2014-04-03 09:12:20 +08:00 1
怕join就把所有字段堆在user里面
|
 |
4
yyai3 2014-04-03 09:14:30 +08:00 1
活到老学到老，用户有没有可能即是学生也是老师？角色设计？
|
|
7
min 2014-04-03 09:38:03 +08:00 1
|
 |
8
lenmore 2014-04-03 10:00:24 +08:00 1
方案B吧
需要join的地方可能就是一些列表而已， 如果真的很在意join的性能，可以建一个索引视图，毕竟更新不会很频繁吧。 |
 |
9
helone 2014-04-03 10:03:49 +08:00 1
方案B吧，方案A坑很大。。。
|
 |
12
merlin852 2014-04-03 10:32:24 +08:00 1
我觉得可以user一张表，再建一个user_prop，保存其他资料，user和user_prop一对多关系
user_prop 可以类似如下： id，user_id, type ，value 1, 10001, 10, xxxx 2, 10001, 20, yyyy 10代表毕业大学，20代表性格，30代表。。。。可以自己定义 这样后续添加其他资料时不用更改表结构，相对好扩展点，检索起来应该也方便，可能sql写起来麻烦点 |
 |
14
mahone3297 2014-04-03 11:36:41 +08:00 1
看来大家都支持方案B啊。。。要么我也方案B吧。。。
不过确实会有纠结，理解lz。。。 |
 |
15
yueyoum 2014-04-03 11:48:49 +08:00 1
这有什么好纠结的
class User(Model): id = ... name = ... passwd = ... ** other properties class Teacher(User): .... class Student(User): .... 注册 登录 找密码 只用关心user表即可 |
 |
16
NetCobra 2014-04-03 12:21:00 +08:00 1
让我选的话我用方案B，再加两个View，Join就留给View去做。
|
|
17
NetCobra 2014-04-03 12:22:21 +08:00
另外User和Teacher，User和Student不应该是一对一关系吧？一个User不应该同时是Teacher和Student。
|
 |
18
sheaven 2014-04-03 13:14:24 +08:00 1
这时候菲关系型数据库就笑了，可行的话考虑下mongodb
|
 |
22
wwek 2014-04-03 13:43:28 +08:00 1
每次看v友都说的很好
我也在啰嗦下 b方案. 共有信息放一张表.独有信息单独放. 这个级别的join操作没关系.如果实在是规模比较大,以后做个中间件丢内存跑吧. |
Select Language