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

[sinux]

detail是一个json字符串。

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

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

[feisan]

@shiznet 恩，我同意你的观点。没错，现在多了很多选择。不过从运维的角度看，MySQL的成熟度是更高的，各种优化、扩展、备份方案都很成熟，熟练的工程师也好找。相对而言，比较新生的一些数据存储服务，在这些方面有待发展。所以我会觉得这个CTO采用这样的方案也是可以理解的。

[kenken]

@est 头像都存到数据库吗？。。 小规模用图片服务器，大规模直接分布式dfs之类。 而且业务检测是肯定要做的，要不然就是bug了。

[lawmil]

哎..我只想说一句..你们大城市人真会玩!

[aksoft]

哎..我只想说一句..你们大城市人真会玩!

[cloudop]

我就问索引怎么办吧？

[cloudop]

除非你们的业务需求非常的特别，并且有一中间层来处理协同程序员和数据库（用mysql这不脱裤子放屁么，用其它类型数据库不好么）。再说了，查询字段，统计加加减减的怎么弄？中间层写不清楚，无数bug出来。开发的时候那坨json里面的字段谁都可以加新字段，有的记录detail有这个字段，有的没有。我去，这想想就带感。

[cloudop]

认真的看了下kenken的发言和7楼的文章，认真想想发现挺颠覆的。我们是做手游的，服务端的部署很麻烦，特别是加新功能动到表结构的时候，要每一服都同步表结构，很是头疼。这种结构很有启发。

[sampeng]

这个方案没问题啊。。。只是颠覆常规思维而已。。
只是这样考虑的问题要多一点。。。
我个人比较在乎的速度。。一个json里面东西多了还是蛮带感的。拉一个列表拉一堆无用的东西出来。
但是如果有个中间层，这就不是问题。如果没有。。。还是别这么玩好，量上去了。速度问题很难优化。

[sampeng]

我刚还想，为啥不redis。。。
如果没有事务要求，redis比mysql更适合一点。
mongo就太重了。。mongo其他组用过，后来出各种奇葩问题。就不怎么用了。。。

[txlty]

怎么没人说是为了将来在各种数据库之间平稳过渡、自由选择？
改个配置参数，就切换一种数据库。这也挺酷炫的。

[jasonding]

坐等 CTO 发帖

[sampeng]

@txlty 炫酷啥。。99%的公司项目是不需要这样的。。
况且切换数据库没那么简单。。。数据同步，停服务还是热切换。。我觉得所谓改个配置参数就切换数据库。纯粹是臆想。。

[cjyang1128]

坐看各位大侠撕逼

[kenken]

其实还有一点是，不是每个detail都存储所有的信息。detail是按照业务纬度划分的，各业务关注的纬度也是不一样的。 每次load不需要load所有detail，只需要load和更新它关注的那一条数据就可以了。

detail的json也是不能无限制增长的，一般我们使用text，65535的长度是完全够用的。 这样给上层带来的灵活度是很不错的。

当然根据不同的业务场景设计肯定是不同的，这个是要灵活配置的。

[mingyun]

基于什么考虑