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

[sinux]

detail是一个json字符串。

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

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

[cobola]

哈哈 你们用的是mysql么？

oracle？

哈哈哈

[superbear]

更新一个字段啥的，还得全部取出，编辑后再组装。。。

[finab]

既然如此，干嘛用数据库？ - -

[superbear]

如果用的是Mysql的话，感觉这样还不如用Mongo...

[sinux]

@cobola
@superbear
@finab

用的就是mysql。

[est]

本来打了很多字，详细分析这种json保存为文本blob到一个字段里的优缺点，结果还是删了。

三个字：然卵用

[scalala]

这就是把关系数据库当KV数据库用, friendfeed 2009年用的方案 http://backchannel.org/blog/friendfeed-schemaless-mysql

[sinux]

@superbear 多对多的表还是有的，只是外键都弄进去了

[Ison]

可能跟业务需求有关系。。。
只对单条id索引读取而又不需要修改的话
其实也不是不可理解
当然。。。也不排除你CTO是奇葩。。。

[roushan]

现在很流行的做法，K/V的方式来设计，有比较高的扩展性。
需要有一套比较强的中间件来支撑会比较好。

[timsims]

但是如果要对detail里某字段进行统计岂不是要把所有数据都取出来，然后再自行计算？

[zkd8907]

看业务吧，如果只是简单的增删改查，不涉及column的order，join操作，这样做还Ok啦。但是既然业务如此，为什么不用nosql数据库。。。

[zieglar]

这种时候就看出 Postgres 的好用了， jsonb 操作简直爽到歪

[scalala]

@timsims 只有小网站才会直接在主业务数据库做统计的, 大流量网站在数据产生的时候就发到MQ让有需要的系统自己订阅

[Kabie]

为啥不用mongo或者pg。。。

mysql还搞这些幺蛾子。。。

[b821025551b]

个人感觉如果业务需求摆在那，几个字段或者表这么存没什么问题；如果都这么存，要数据库干嘛？

[nigelvon]

为啥不用mongo+1，mysql完全没用上啊。

[scalala]

mongo和这套方案完全不搭界, mongo的好处是schema-less,即数据结构很自由.
这套方案拿mysql当KV数据库用纯粹是为了性能.

[jarlyyn]

自己这边的的表基本也是这样的，多一个字段表示下数据处理的model类的keyword.
只有需要排序的字段再单独列出。

业务决定的。需要同一套代码管理不同项目的数据，只能在数据上增加弹性。

不过他的理由我不太懂。。

[nigelvon]

@scalala 撸主说的那种方式也是自由结构呀，一个JSON字符串，想放什么就放什么。另外求解释这种方式怎么利用MySQL的性能。