作者tao2tw (smile_ting)
看板PHP
标题Re: [请益]如何设计 facebook , g+ 按赞或者+1的功能
时间Sun Mar 24 23:08:23 2013
1F：→ MOONRAKER:这样只在一个方向勉强算有效率 反过来就超级没效率 03/24 16:00
2F：→ MOONRAKER:你想一下(1)我现在又按一次赞，怎麽避免我重覆。 03/24 16:01
3F：→ MOONRAKER:(2)我现在要收回赞，怎麽把我收回。 03/24 16:01
4F：→ MOONRAKER:(3)我现在想知道我按过哪些赞(FB界面没提供，但是API有)03/24 16:02
5F：→ MOONRAKER:要怎麽办。你想一下在你设计中怎麽快速处理这三个功能。03/24 16:02
回覆 Moo大的建议，
这边我自己思考了一下。
我会考虑把 like 独立做成一个table
栏位可能就是.
post_id user_id
就这样, post_id 表示 此like 跟随哪一篇post , user_id 则是表明是谁按的赞
如此一来。
如果我需要知道 某篇post 有谁按过赞 就去搜寻 like TABLE , where post_id = XXX
同样的我也可以在 like Table , where user_id = me
去找寻我like过哪些post
如果要收回like ， 只要delete 即可。
只是这样一想，觉得fb是在是太威猛了。
如果每次都要读写回database 感觉会很消耗系统资源。
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 119.77.136.156
6F：→ MOONRAKER:MOONRAKER不是Moo 我拒绝这个简写 X( 03/24 23:30
7F：→ MOONRAKER:去年我接触一个站改版 他也有这种"A,B,C"式的资料栏位 03/24 23:31
8F：→ MOONRAKER:虽然那只是分类 例如一张相片同时属於人物,旅行,心情类 03/24 23:32
9F：→ MOONRAKER:不会像「赞」那麽频繁读写 仍然使我们干得要死 XD 03/24 23:32
10F：→ MOONRAKER:可那个站以前也还能够营运那麽久还不出事情 可能的解释 03/24 23:33
11F：→ MOONRAKER:就是这样设计对资料库的压力究竟如何 也不是那麽简单 03/24 23:34
12F：推 gpmm:推一个自己想，压力这件事可以用 memcache 来解啊 XD 03/24 23:55
13F：推 chenlarry:FB的效能是用钱砸出来的，他们买很多记忆体，但到底有多 03/25 00:31
14F：→ chenlarry:少我不记得了，但我印象中很大，非常大... 03/25 00:31
15F：→ chenlarry:刚刚查了一下资料，FB有800台伺服器，记忆体有28TB.... 03/25 00:37
16F：推 sin282:AKER大 正名 03/25 14:08
17F：→ alpe:FB印象中用了不少NoSQL的方案. 03/26 00:18