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

哈哈 你们用的是mysql么？

oracle？

哈哈哈

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

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

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

@cobola
@superbear
@finab

用的就是mysql。

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

三个字：然卵用

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

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

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

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

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

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

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

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

为啥不用mongo或者pg。。。

mysql还搞这些幺蛾子。。。

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

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

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

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

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

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

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

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

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

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

mariadb 现在好像支持json了。

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

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

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

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

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

不是说 MySQL 要支持 json 了么？

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

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

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

@matsuijurina

和性能没关系啊。

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

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

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

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

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

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

需求决定一切么。

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

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

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

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

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

这样用还不如直接用 nosql

坐等 CTO 发帖

@moro 哈哈哈哈哈哈。

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

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

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

@FrankFang128 最近v2成了撕逼社区

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

直接上nosql啊

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

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

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

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

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

这个用 redis mongodb 吧哈哈

果断上postgresql啊

有查询条件怎么办？

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

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

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

坐等cto来撕哔

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

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

BTW: 我是CTO

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

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

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

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

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

@kenken 明白了，thank you.

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

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

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


hahahahaha

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

@shuson ....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@yuankui He's right there....

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

@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.持赞同

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

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

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

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

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

这种设计有好处有坏处

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

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

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

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

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

postgrep大法好

挺好。

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

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

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

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

@fy 是mysql 5.6

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

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