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

[sinux]

detail是一个json字符串。

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

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

[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 发帖