CTO，新设计的所有的表都只有 id 和 detail。我不是很理解，求解释。

[sinux]

detail是一个json字符串。

原来的所有的外键和column全都都放到detail里面。

他说这样可以避免外键的混乱和冲突，自己来维护外键关系。

[zongwan]

@kenken
是游戏服务器适合这种结构吗?
如果需要合服(玩家带着的所有道具,道具有自己的强化等级等),克隆多个用户去同一个PK服
有什么trick方法处理吗?

[yuankui]

你确定你们的CTO不上v2ex吗？

[superisaac]

这种用mysql作kv有个卵的性能。
为啥不用tokumx?

[nino789pzw]

@yuankui He's right there....

[arbipher]

别撕了，别撕了，看新闻
MySQL 5.7.7 JSON labs release
http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

[shiznet]

@feisan 看了下7楼的文章，写于2009年。我查了下wiki，nosql在09年才开始普及(不知道这样说可以么)。如果放到现在的话，friendfeed还会继续选择使用mysql做kv存储么，我个人表示怀疑。

不过我对将mysql作为schema-less的存储持中立，对文章中提到的：scaling our existing features to accomodate more traffic turned out to be much less of an issue than adding new features.持赞同

[falcon05]

一开始我也准备喷为毛不用nosql，但看完了7楼的链接，我发现这样做还真有点道理，一种典型的用空间换时间的做法，充分利用了索引和MySQL较为成熟事务处理，可以做到快速查询跟安全存储，而且扩展性也不错。配合异步处理和自动化，就是一套完整的解决方案

[pubby]

看业务需要了，在一些业务需求多变的场合，当kv用，或者部分column当kv用有时候还是很方便的。

[cevincheung]

@kenken 事物指的不是单纯的操作成功，在事物过程中的其他计算才是最关键的。如果说表结构是类似这样：

users: id, detail
orders: id, detail
logs: id, detail

那为什么不干脆是一个表？或者有什么理由不去用mongodb？（事物不算，而且实现软事物并不难）

[lyragosa]

这种设计有好处有坏处

喷的人一定没遇到非常复杂的多层嵌套结构

当然你非要严格按照二范氏做他几十个表我也没办法反驳……

[JoeShu]

以前做过类似的设计，不过稍有区别，就是要把索引字段需要抽取出来，不然性能会很差
优点很多：
1. 处理灵活，适合业务变化比较快的产品
2. 支持事物，适合对数据一致性要求高的场景
3. 支持行级锁，因为直到2.4版本，mongodb还只支持db级别的锁
4. mysql要比mongodb稳定的多，各种问题都有很成熟的解决方案
5. 很多云服务和运维服务不支持nosql。
6. 性能问题，mongodb对内存和磁盘空间的消耗实在是很大，尤其内存小于热数据的时候。

这种方案是综合了mysql和nosql的优点， 是一种很好的解决方案

[monkeylyf]

也用过类似的schema设计 用postgres来实现 主要是为了灵活的应付需求改变 减少修改schema导致的db migration 稳定后的release的时候会把json里的数据拉出来当成col存

[decken]

postgrep大法好

[guotie]

挺好。

我们在每个表里增加一个attr的字段，json结构，专门用来扩展。

[CharlesL]

看V2的大侠们讨论，果然长知识.

[kenken]

@est 1M的json，那就得分离存储了，特殊情况需要特殊设计。但是1m这情况我这么多年也没遇到，这情况一般人会放到单纯的mysql吗？

[est]

@kenken 你永远无法预测用户会给你传什么东西上来。。。。reddit 他们就遇到这个事情了。好像是用户头像哪里？他们忘记做检测了。结果有个用户头像大小是2G。

[kenken]

@fy 是mysql 5.6

[kenken]

@zongwan 这个对游戏确实不熟悉，一直在做电商。 像合服我听过，但不了解是怎么操作。

[kenken]

@JoeShu 对，我们是电商，对事务要求极其严格，而且行级锁性能是非常高的。