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操作没关系.如果实在是规模比较大,以后做个中间件丢内存跑吧. |