V2EX › caoyue 的所有回复 › 第 10 页 / 共 36 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 6 7 8 9 10 11 12 13 14 15 ... 36

❮

❯

2015 年 4 月 22 日

回复了 iqav 创建的主题 › iPhone › 夏天 Touch ID 经常失效，你是怎么避免的？

录入手指关节附近的「指纹」，我这个地方汗比较少=-=

2015 年 4 月 21 日

回复了 solaro 创建的主题 › 数据库 › QQ 里的‘好友动态’，微信里的‘朋友圈’该怎么设计表结构呢？

@explon
从 *朋友圈* 看到和点头像进个人的 *Profile* 看到是两个逻辑

测试方法：
1. A 和 B 是好友
2. A 和 B 互相删除好友
3. A 发布一条朋友圈
4. A 和 B 互相加为好友
5. A 刚发布的更新不会出现在 B 的朋友圈
6. B 在 A 的 Profile 页面可以看到 A 的更新

如果 A 和 B 本来就不是好友，1 和 2 可以忽略

2015 年 4 月 21 日

回复了 solaro 创建的主题 › 数据库 › QQ 里的‘好友动态’，微信里的‘朋友圈’该怎么设计表结构呢？

@xenme
@explon
@huijiewei
1. 我之前做过测试，微信朋友圈新加的好友是**看不到**之前的设置为好友可见的更新的，目前看来不存在新加的拷贝问题
2. 刷新朋友圈的时候，是只读一个表还是读五十个表方便嘛
3. 占用空间不叫事
4. 我只是猜一个思路，不用局限到关系数据库还是缓存还是别的什么东西上
5. 任何一个复杂到朋友圈级别的系统，都不是单单数据库能解决的问题
6. 不存在什么牛逼的单个工具，用了就能支撑起这么复杂的系统
7. Push 和 Pull 模式还有 Feed 架构已经讨论了这么多年了，楼主可以找资料参考

2015 年 4 月 21 日

回复了 jookr 创建的主题 › MySQL › Mysql 里 insert into select from 这种用法的特殊需求该怎么写？

@jookr
我从你上面复制的=-= 没注意

2015 年 4 月 21 日

回复了 jookr 创建的主题 › MySQL › Mysql 里 insert into select from 这种用法的特殊需求该怎么写？

Insert into table(name,telphone,age) select name,'1388888‘,age from table where name='tom'

2015 年 4 月 21 日

回复了 solaro 创建的主题 › 数据库 › QQ 里的‘好友动态’，微信里的‘朋友圈’该怎么设计表结构呢？

瞎猜一个，如果是我可能这么设计：
假设 A 和 B 关注了 C，C 发布了一条更新
那么把这条更新同时写到 A，B 各自的关注表里面去
A 和 B 各自读自己的关注表就行了
这样算起来，单独看个人的数据量就没有那么大了=-=

2015 年 4 月 17 日

回复了 tonyrft 创建的主题 › 分享发现 › [Humble Bundle]EA 慈善包第二季来啦=w=

上次买的好像都还没来得及玩=-=

2015 年 4 月 16 日

回复了 lzsadam 创建的主题 › 问与答 › 表妹下月要去日本旅游，想帮我捎东西，带什么比较好？

冈本001

朋友圈好像有人在代购这个（捂脸

2015 年 4 月 15 日

回复了 Galvin 创建的主题 › 职场话题 › 应届生的工资就应该低吗？

跟是不是应届生没关系，跟楼主展现的能力也没关系
要么他们只需要 4k 水平的员工，要么他们穷/抠到只开得起 4k

2015 年 4 月 11 日

回复了 spencerqiu 创建的主题 › 健身 › 本人是 90kg / 180cm 的胖子，坚持每天跑步 2-3km 两周多，每天的量还在慢慢上，但是感觉肚子、胸部的肉是大难题，大家有啥办法？

结合 HIIT 一起比较有效果，单纯慢跑好像确实对减肥效果不是太明显

2015 年 4 月 9 日

回复了 luent 创建的主题 › 问与答 › C# 公共 Hashtable 变量在一个 System.Timers.Timer 中能改变值，但是 remove 后，下次为什么还有啊？

贴个完整点的代码比较方便看问题吧=-=

2015 年 4 月 9 日

回复了 ajianrelease 创建的主题 › MySQL › 乐观锁与悲观锁各自适用场景是什么？

@ajianrelease
对数据库了解不多，个人感觉哈 :)
1. 一般场景下竞争冲突的时候不多。除非完全不可接受的情况，使用乐观锁比较常见。
2. 有些 ORM 是内建乐观锁支持的
3. 这种情况下要使用悲观锁，可以在更新前做一次 select for update
4. 互联网应用有时候对数据一致性的要求没有那么高
5. 有些场景会用到多级缓存缓解这些问题
6. 如果是数据正确性很重要比如金融业务之类，加上操作日志是更保险的做法

2015 年 4 月 9 日

回复了 ajianrelease 创建的主题 › MySQL › 乐观锁与悲观锁各自适用场景是什么？

我的理解是，数据库只能保证操作的结果正确而不能替你做业务逻辑上的「正确」
题目所说的场景可以将读和写作为一个事务，同时选择合适的隔离级别。
当然更高的隔离级别也意味着更低的并发
如楼上所说，两种方式开销都不小，具体怎么实现取决于楼主的场景

2015 年 4 月 9 日

回复了 KentY 创建的主题 › 程序员 › 还有喜欢写字的程序员吗？

一般压抑烦躁的时候喜欢瞎写瞎画，感觉不错

2015 年 4 月 7 日

回复了 bellchu 创建的主题 ›  WATCH › 相比智能手表，机械表更体现人类的智慧

谈不上智慧，无非是「情怀」=-=

2015 年 3 月 30 日

回复了 jacob 创建的主题 › 分享发现 › 李健不愧是理工男

之前还冒出个「2 是素数里面的第一位」……
不过这些都是段子属于锦上添花:)
李健确实特别聪明而且理性，看他的采访提到的一些观点很让人佩服