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的性能。

[DjvuLee]

@scalala mongo 是一个document类型的数据库。它把一个json看成是一个document，怎么会不搭界呢？况且mongo有sharding操作，以后也方便扩展。

[DjvuLee]

大家都说的很好。如果只是这样，要么使用k-v数据库，要么使用内置json处理的postgresql。或是lz有一些其他考虑没有提到？

[learnshare]

他这种用法，是文档数据库，用 MySQL 不合适。

[mathgl]

mariadb 现在好像支持json了。

[matsuijurina]

@jarlyyn 我觉得你的说法是比较有道理的。主要是适应多种业务模式增加数据弹性。用MySQL做KVS真的能在性能上超过MongoDB吗？ 我有点怀疑。

[winnie2012]

这个设计有点反常规，看看各位大牛如何吹。

[scalala]

@nigelvon 把20字段都放一个json存取性能是比一个20字段的mysql表存取性能要好的. 这个方案当然也是附带了schemaless的作用.
这样做其实就是要弱化数据库的作用,排序什么的都在应用里做(或者把需要排序的字段抽出来做索引).
这种事本来应该用专门的KV数据库的, 估计楼主的CTO是考虑到MySQL比较成熟/熟悉.(运维等各方面都要考虑)

[nanhuo]

关系型数据库设计成这样是要闹哪样？干吗不用mongo

[pijingzhanji]

你CTO中了NoSQL的毒，这样还用什么mysql，用redis算了

[ichou]

不是说 MySQL 要支持 json 了么？

[nigelvon]

@scalala 存取性能好没用啊，而且也好不过mongo，关键是怎么查。如果不需要查的话，要MySQL干甚。

[neoblackcap]

@scalala 我觉得这样做大概是为了拓展好（KV貌似没有不好），不过以前没有大批nosql数据库之前这样做我理解啊，但是现在还这样做，我真是不能理解了。我是很难想象mysql在这个方面可以跑赢mongodb的。

所以嘛，现在的话，关系型数据就应该按照关系型数据的用法，不是关系型数据的逻辑应该放在nosql数据库中处理，没有哪个规定应用一定要只用一种数据

[jarlyyn]

@matsuijurina

和性能没关系啊。

很基本的道理，我的业务必要考虑到可能在虚拟主机上使用。

所以必须支持php 5.2/5.3,必须使用mysql。

我这里的业务是给企业建站的。

如果企业需要要给某个栏目添加一个视频，需要添加一个作者，需要添加一个副标题，需要添加一个简介，需要添加一组幻灯片。

难道我还去调整数据库么？

直接继承下model的基类，添加两个自动序列化/反序列化的类，后台就自动多了输入框了。然后视图里用个getModelValue('xxx')方法，就完工了。

需求决定一切么。

[cdffh]

他不会有涉及json内部的查询吗? 查询全是基于id的? 如果没有就没啥问题.

[mhycy]

@jarlyyn 那么为了性能至少还需要一个永不重复的type字段, 以路径形式命名...

[zhicheng]

这跟 friendsfeed 的设计不一样好嘛。
一般来讲，这事儿就是 CTO 蛋疼。一个不折腾的 CTO 也是公司之福。

[jsq2627]

文档数据库是最佳选择。
在应用层做数据约束好处是可以很方便的水平扩展。坏处是如果没有很清晰的文档和规范，基本没人能 100% 做到位。

[moro]

我在想，会不会有题主的CTO来开贴。。

[finian]

这样用还不如直接用 nosql

[FrankFang128]

坐等 CTO 发帖

[MrEggNoodle]

@moro 哈哈哈哈哈哈。

[roricon]

是新增的表全都长这样，还是所有的表全都这样？
如果全部表都这样，查询性能怎么解决……这样做是完全抛弃主键以外的索引了么？

[jarlyyn]

@mhycy
当然不是，留一个关键字。

至于关键字对应的类文件，在一个配置文件里定义。

[Lullaby]

@FrankFang128 最近v2成了撕逼社区

[quix]

这是典型的把 rdbms 当 nosql 来用... 某些情况下确实也可以..

[hkongm]

直接上nosql啊

[quix]

对于不需要索引的内容字段, Lz 的 cto 这样做应该无伤大雅.

[soli]

几乎所有人都盯着业务、性能、查询、索引。。。

好像只有 @scalala 提到了成熟度和运维。

[loading]

我很多时候会在里面存json的kv数据，例如设置信息，这样就不会因为后面增加功能而担心没字段存了，一个字段全存完！

可是像楼主描述那样，这个字段不都是一样的内容吗？

[yangzh]

这个用 redis mongodb 吧哈哈

[cevincheung]

果断上postgresql啊

[langhua9527]

有查询条件怎么办？

[9hills]

NoSQL没问题，但是用MySQL不太好。。

[wbolor]

记得很早前看过一篇文章 reddit 好像就是这么搞的。。。

[sivacohan]

是"只有"，还是"都有"
如果是都有的话，可以理解，id做主键，主键和业务无关是有优势的。detail应对来自其他部门的乱七八糟的需求。
如果是只有的话就有点奇怪了。这完全放弃了SQL啊。每次查询点什么都是全表扫描，相当于应用层实现了一个SQL，图什么啊?而且数据量上去了，你把所有的数据都放应用里，不怕内存爆了吗?前端应用至少两个吧，你怎么保持数据的一致性?
如果你的CTO能有理有据的解释我上面的问题，请你一定告诉我。我之前也遇到过类似的架构，解释就是移植性好，后面数据库随便换，这个理由我完全接受不了。

[Mirana]

坐等cto来撕哔

[kenken]

我们就是这么玩的。 我们现在id和detail detail使用json存储。
1，运维成熟，稳定性更高。安全性非常高
2，搜索用elasticsearch单独做。速度更快，比mysql量级高很多，分词灵活
3，数据分析有hadoop，hive等工具。以及离线的其他pg，或者elasticsearch做运维系统。
4，最初设计也是上层的灵活性。上层字段添加非常多，业务开发也很频繁。1000+个字段的表无法每个字段都存储的。
5，很重要的支持事务。

[scys]

找CTO撕逼~
我自己设计的MongoDB设计的结构，直接被新来的CTO。
一口说，MYSQL是最好的，我们还MYSQL~
结果~我自己就去做前端了~

[kenken]

BTW: 我是CTO

[icqdany]

@kenken
请问第5点的，事务是怎么做的？

[coney]

@kenken 还是不懂，为什么不用mongodb

[kenken]

@icqdany 大于一个表的更新 插入操作是事务的。这个是nosql很难实现的。

[hcymk2]

@kenken
这样怎么做聚合统计？
用代码实现么？

[adjusted]

坐等ceo偶然看到帖子来发帖

[icqdany]

@kenken 明白了，thank you.

[abscon]

似乎听到了 MySQL 在幽怨地唱着：原来你，什么都不想要~

[kenken]

@hcymk2 第2，3点。 聚合统计elasticsearch是支持的。 离线的用hadoop等大数据分析

[est]

@kenken 这样做是可以的，直到你的json blob撑到了1M，然后你需要从1000个这样的json里取一个1字节的int出来排序。


hahahahaha

[shuson]

我就是CEO，我CTO是我小舅子，他爱咋做我都支持

[sinux]

@shuson ....

[20131115]

@kenken 看起来有你自己的道理，MySQL 不是这么用的，都搞成JSON，如果你增加删除字段的时候怎么操作呢？会不会增加 DBA 的运维成本。你不这样做也可以使用各种搜索服务，也可以使用各种大数据产品

[duwei]

建立楼主加上相关的项目背景。脱离背景讨论没有意义。

[Tink]

我感觉要是业务需求每次都需要取整个detail的话，那这样倒也不失一种办法。当然是在不换数据库的情况下

[galenzhao]

对 nosql事务是个纠结的地方
好多业务逻辑 排除不掉事务。。。
不知道cto研究过SequoiaDB没

[feisan]

建议大家看看7楼说的那篇文章，这样的设计也不是没有道理的。

另外mogodb这个东西，不要光顾着写代码用的爽，也要考虑一下运维的难度和成熟度。

[br00k]

批量修改操作我想知道效率会怎样。。

[fy]

@kenken 请问数据库是postgress吗？我想知道这种情况下，数据库会不会帮你把相同的key整合优化掉，所以数据库会比原本的json更省空间？

[franksin]

说说使用场景呗，有些特殊场景，kv也可能比较好用。

[ksupertu]

现在的主流设计本来就不用数据库提供的外键啊，都是自己维护一套主外键代码

[michaelye1988]

我也是这样做的，我觉得很方便。现在接手的一个Android项目就遇到这个问题。服务端需要增加一个字段非常麻烦，客户端需要升级数据库。所以如果没有特别的需求，我觉得你们CTO做的没错。

[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 对，我们是电商，对事务要求极其严格，而且行级锁性能是非常高的。