[求助] 请教大家一个数据库设计的问题

[hustlzp]

网站的用户分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操作。

大家的看法是？或者有更好的设计方案，非常感谢！

[jones]

以ORM的思维来说肯定是第二种，join一般不用担心，现代的ORM都带有延迟加载和缓存的功能，查询一个user对象其实也就一条普通的select，对象中只持有老师或学生的关联id，调用user的get老师方法的时候，ORM会自动去加载老师的数据，首先查找缓存，没有找到在另外发送一条SELECT，然后把返回的老师数据放入缓存中，当然这只是理想情况下，

[hustlzp]

@jones 感谢！第二种确实合适些~

[min]

怕join就把所有字段堆在user里面

[yyai3]

活到老学到老，用户有没有可能即是学生也是老师？角色设计？

[hustlzp]

@yyai3 这种情况极其少，所以暂不考虑，强制某用户只有一个role。如果需要新的role，需重新注册。

[hustlzp]

@min 恩，考虑过，只不过差异的部分太大，会造成太多冗余字段，所以权衡后，还是join吧...

[min]

@hustlzp
这个做法是一些orm里面处理继承结构的推荐做法，速度相对快
冗余不冗余的，如果你用的orm能管好数据库的结构，也不是个问题

[lenmore]

方案B吧
需要join的地方可能就是一些列表而已，
如果真的很在意join的性能，可以建一个索引视图，毕竟更新不会很频繁吧。

[helone]

方案B吧，方案A坑很大。。。

[hustlzp]

@min 有道理，得去好好看看SQLAlchemy中的继承处理方法。

[hustlzp]

@min
@lenmore 恩，想了下，如果A的话坑确实不少...

[merlin852]

我觉得可以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写起来麻烦点

[hustlzp]

@merlin852 懂你意思了，这样灵活度很高，扩展很强啊~

[mahone3297]

看来大家都支持方案B啊。。。要么我也方案B吧。。。
不过确实会有纠结，理解lz。。。

[yueyoum]

这有什么好纠结的

class User(Model):
id = ...
name = ...
passwd = ...

** other properties


class Teacher(User):
....

class Student(User):
....


注册 登录 找密码 只用关心user表即可

[NetCobra]

让我选的话我用方案B，再加两个View，Join就留给View去做。

[NetCobra]

另外User和Teacher，User和Student不应该是一对一关系吧？一个User不应该同时是Teacher和Student。

[sheaven]

这时候菲关系型数据库就笑了，可行的话考虑下mongodb

[hustlzp]

@yueyoum 感谢！万能的V2EX！

[hustlzp]

@sheaven 恩，非结构化确实方便！