1
Livid MOD 我的猜测,不知道对不对?
A 是用户 B 是行为或者条件 C 是成就系统里的单项成就 |
2
supersheep OP 怪我,说得太隐晦了。我想的是“用户对问题做出看法”,表达出来应该是“A对B作C观”。
A是用户,B话题(其实也可以是其他任何形式),C是观点。 这里A和C的关系不是特别重要,不过如果要做推荐算法的话就会有意义了。 |
3
supersheep OP @Livid 又忘记艾特= =
|
4
chloerei 2011-03-27 15:08:43 +08:00
sql
users( id, ... ) problems( id, ... ) users_problems( user_id, problem_id ) viewpoints( id, ... ) problems_viewpoints( user_id, problem_id, viewpoint_id, ... ) MongoDB users: { _id : ..., ... } problems: { _id : ..., ... , viewpoints : [ { user_id : ..., viewpoint : ... }, { user_id : ..., viewpoint : ... } ] } |
5
chloerei 2011-03-27 15:10:04 +08:00
…… 我想编辑
|
6
Livid MOD @supersheep 你的这个问题会需要用到 3 张以上的表。
|
7
chloerei 2011-03-27 15:11:41 +08:00
sql
users( id, ... ) problems( id, ... ) viewpoints( id, user_id, problem_id, ... ) 4 楼黑历史了 |
8
Livid MOD |
10
supersheep OP @chloerei 不知道你写的users_problem是作何用,如果是用户创建的话题,可以把creator直接作为话题的字段。如果是参与话题,则problem_viewpoints里就可以拿到了。
我之前就是除了user,topic,viewpoint之外,还需要类似你的problems_viewpoints这样一个表,还是将这个表中的三个字段两两结合拆成三个表这样子。 btw,第一次看到MongoDB的写法,很诱人的样子啊。 |
11
supersheep OP 刚和公司的DBA同学探讨了一下。我原本的期望是这个viewpoint可以单独拿出来,对于不同的问题可以运用同一个viewpoint,后来觉得这样太琐碎了,没特别大必要……
还有一点就是提倡适度的冗余来防止表关连查询…… |
12
chloerei 2011-03-27 15:39:05 +08:00
@supersheep 7楼为准,4楼在发出时候发现自己犯傻了,在看漫画脑子不清楚
|
13
chloerei 2011-03-27 15:40:35 +08:00
@supersheep 感觉 viewpoint 冗余度不高吧,除了“沙发”“赞成”这样的观点。
|
14
supersheep OP @chloerei 嗯。在看这篇文章 http://icyleaf.com/2008/06/21/tags-database-schemas/ 感觉和我的需求有点像。对数据库还不是特别娴熟啊。
|