detail是一个json字符串。
原来的所有的外键和column全都都放到detail里面。
他说这样可以避免外键的混乱和冲突，自己来维护外键关系。
原来的所有的外键和column全都都放到detail里面。
他说这样可以避免外键的混乱和冲突，自己来维护外键关系。
› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
This topic created in 4178 days ago, the information mentioned may be changed or developed.
 |
cobolaMay 27, 2015
1
哈哈 你们用的是mysql么？
oracle？ 哈哈哈 |
 |
superbearMay 27, 2015
2
更新一个字段啥的，还得全部取出，编辑后再组装。。。
|
 |
3
既然如此，干嘛用数据库？ - -
|
1 |
superbearMay 27, 2015
4
如果用的是Mysql的话，感觉这样还不如用Mongo...
|
 |
estMay 27, 2015
6
本来打了很多字，详细分析这种json保存为文本blob到一个字段里的优缺点，结果还是删了。
三个字：然卵用 |
 |
7
这就是把关系数据库当KV数据库用, friendfeed 2009年用的方案 http://backchannel.org/blog/friendfeed-schemaless-mysql
|
 |
IsonMay 27, 2015
9
可能跟业务需求有关系。。。
只对单条id索引读取而又不需要修改的话 其实也不是不可理解 当然。。。也不排除你CTO是奇葩。。。 |
 |
roushanMay 27, 2015
10
现在很流行的做法，K/V的方式来设计，有比较高的扩展性。
需要有一套比较强的中间件来支撑会比较好。 |
 |
timsimsMay 27, 2015
11
但是如果要对detail里某字段进行统计岂不是要把所有数据都取出来，然后再自行计算？
|
 |
zkd8907May 27, 2015
12
看业务吧，如果只是简单的增删改查，不涉及column的order，join操作，这样做还Ok啦。但是既然业务如此，为什么不用nosql数据库。。。
|
 |
zieglarMay 27, 2015
13
这种时候就看出 Postgres 的好用了， jsonb 操作简直爽到歪
|
 |
KabieMay 27, 2015
15
为啥不用mongo或者pg。。。
mysql还搞这些幺蛾子。。。 |
 |
b821025551bMay 27, 2015
16
个人感觉如果业务需求摆在那，几个字段或者表这么存没什么问题；如果都这么存，要数据库干嘛？
|
 |
nigelvonMay 27, 2015
17
为啥不用mongo+1，mysql完全没用上啊。
|
|
scalalaMay 27, 2015
18
mongo和这套方案完全不搭界, mongo的好处是schema-less,即数据结构很自由.
这套方案拿mysql当KV数据库用纯粹是为了性能. |
 |
jarlyynMay 27, 2015
19
自己这边的的表基本也是这样的，多一个字段表示下数据处理的model类的keyword.
只有需要排序的字段再单独列出。 业务决定的。需要同一套代码管理不同项目的数据，只能在数据上增加弹性。 不过他的理由我不太懂。。 |
 |
DjvuLeeMay 27, 2015
21
@scalala mongo 是一个document类型的数据库。它把一个json看成是一个document，怎么会不搭界呢？况且mongo有sharding操作，以后也方便扩展。
|
|
DjvuLeeMay 27, 2015
22
大家都说的很好。如果只是这样，要么使用k-v数据库，要么使用内置json处理的postgresql。或是lz有一些其他考虑没有提到？
|
 |
learnshareMay 27, 2015
23
他这种用法，是文档数据库，用 MySQL 不合适。
|
 |
mathglMay 27, 2015
24
mariadb 现在好像支持json了。
|
 |
matsuijurinaMay 27, 2015
25
@jarlyyn 我觉得你的说法是比较有道理的。主要是适应多种业务模式增加数据弹性。用MySQL做KVS真的能在性能上超过MongoDB吗？ 我有点怀疑。
|
 |
E2gCaBAT5I87sw1MMay 27, 2015
26
这个设计有点反常规，看看各位大牛如何吹。
|
|
scalalaMay 27, 2015
27
@nigelvon 把20字段都放一个json存取性能是比一个20字段的mysql表存取性能要好的. 这个方案当然也是附带了schemaless的作用.
这样做其实就是要弱化数据库的作用,排序什么的都在应用里做(或者把需要排序的字段抽出来做索引). 这种事本来应该用专门的KV数据库的, 估计楼主的CTO是考虑到MySQL比较成熟/熟悉.(运维等各方面都要考虑) |
 |
nanhuoMay 27, 2015
28
关系型数据库设计成这样是要闹哪样？干吗不用mongo
|
 |
pijingzhanjiMay 27, 2015
29
你CTO中了NoSQL的毒，这样还用什么mysql，用redis算了
|
 |
ichouMay 27, 2015
30
不是说 MySQL 要支持 json 了么？
|
 |
neoblackcapMay 27, 2015
32
@scalala 我觉得这样做大概是为了拓展好（KV貌似没有不好），不过以前没有大批nosql数据库之前这样做我理解啊，但是现在还这样做，我真是不能理解了。我是很难想象mysql在这个方面可以跑赢mongodb的。
所以嘛，现在的话，关系型数据就应该按照关系型数据的用法，不是关系型数据的逻辑应该放在nosql数据库中处理，没有哪个规定应用一定要只用一种数据 |
|
33
@matsuijurina
和性能没关系啊。 很基本的道理，我的业务必要考虑到可能在虚拟主机上使用。 所以必须支持php 5.2/5.3,必须使用mysql。 我这里的业务是给企业建站的。 如果企业需要要给某个栏目添加一个视频，需要添加一个作者，需要添加一个副标题，需要添加一个简介，需要添加一组幻灯片。 难道我还去调整数据库么？ 直接继承下model的基类，添加两个自动序列化/反序列化的类，后台就自动多了输入框了。然后视图里用个getModelValue('xxx')方法，就完工了。 需求决定一切么。 |
 |
cdffhMay 27, 2015
34
他不会有涉及json内部的查询吗? 查询全是基于id的? 如果没有就没啥问题.
|
 |
zhichengMay 27, 2015
36
这跟 friendsfeed 的设计不一样好嘛。
一般来讲，这事儿就是 CTO 蛋疼。一个不折腾的 CTO 也是公司之福。 |
 |
37
文档数据库是最佳选择。
在应用层做数据约束好处是可以很方便的水平扩展。坏处是如果没有很清晰的文档和规范，基本没人能 100% 做到位。 |
 |
38
我在想，会不会有题主的CTO来开贴。。
|
 |
finianMay 27, 2015
39
这样用还不如直接用 nosql
|
 |
FrankFang128May 27, 2015
40
坐等 CTO 发帖
|
 |
MrEggNoodleMay 27, 2015
41
@moro 哈哈哈哈哈哈。
|
 |
roriconMay 27, 2015
42
是新增的表全都长这样，还是所有的表全都这样？
如果全部表都这样，查询性能怎么解决……这样做是完全抛弃主键以外的索引了么？ |
 |
LullabyMay 27, 2015
44
@FrankFang128 最近v2成了撕逼社区
|
 |
quixMay 27, 2015
45
这是典型的把 rdbms 当 nosql 来用... 某些情况下确实也可以..
|
 |
hkongmMay 27, 2015
46
直接上nosql啊
|
|
quixMay 27, 2015
47
对于不需要索引的内容字段, Lz 的 cto 这样做应该无伤大雅.
|
 |
loadingMay 27, 2015 via Android
49
我很多时候会在里面存json的kv数据，例如设置信息，这样就不会因为后面增加功能而担心没字段存了，一个字段全存完！
可是像楼主描述那样，这个字段不都是一样的内容吗？ |
 |
yangzhMay 27, 2015 via iPhone
50
这个用 redis mongodb 吧哈哈
|
 |
cevincheungMay 27, 2015
51
果断上postgresql啊
|
 |
langhua9527May 27, 2015
52
有查询条件怎么办？
|
 |
9hillsMay 27, 2015 via iPhone
53
NoSQL没问题，但是用MySQL不太好。。
|
 |
wbolorMay 27, 2015
54
记得很早前看过一篇文章 reddit 好像就是这么搞的。。。
|
 |
sivacohanMay 27, 2015 via Android
55
是"只有"，还是"都有"
如果是都有的话，可以理解，id做主键，主键和业务无关是有优势的。detail应对来自其他部门的乱七八糟的需求。 如果是只有的话就有点奇怪了。这完全放弃了SQL啊。每次查询点什么都是全表扫描，相当于应用层实现了一个SQL，图什么啊?而且数据量上去了，你把所有的数据都放应用里，不怕内存爆了吗?前端应用至少两个吧，你怎么保持数据的一致性? 如果你的CTO能有理有据的解释我上面的问题，请你一定告诉我。我之前也遇到过类似的架构，解释就是移植性好，后面数据库随便换，这个理由我完全接受不了。 |
 |
MiranaMay 27, 2015
56
坐等cto来撕哔
|
 |
57
我们就是这么玩的。 我们现在id和detail detail使用json存储。
1，运维成熟，稳定性更高。安全性非常高 2，搜索用elasticsearch单独做。速度更快，比mysql量级高很多，分词灵活 3，数据分析有hadoop，hive等工具。以及离线的其他pg，或者elasticsearch做运维系统。 4，最初设计也是上层的灵活性。上层字段添加非常多，业务开发也很频繁。1000+个字段的表无法每个字段都存储的。 5，很重要的支持事务。 |
 |
scysMay 27, 2015
58
找CTO撕逼~
我自己设计的MongoDB设计的结构，直接被新来的CTO。 一口说，MYSQL是最好的，我们还MYSQL~ 结果~我自己就去做前端了~ |
|
kenkenMay 27, 2015
59
BTW: 我是CTO
|
 |
adjustedMay 27, 2015
64
坐等ceo偶然看到帖子来发帖
|
 |
66
似乎听到了 MySQL 在幽怨地唱着：原来你，什么都不想要~
|
 |
shusonMay 27, 2015
69
我就是CEO，我CTO是我小舅子，他爱咋做我都支持
|
 |
20131115May 27, 2015
71
@kenken 看起来有你自己的道理，MySQL 不是这么用的，都搞成JSON，如果你增加删除字段的时候怎么操作呢？会不会增加 DBA 的运维成本。你不这样做也可以使用各种搜索服务，也可以使用各种大数据产品
|
 |
duweiMay 27, 2015
72
建立楼主加上相关的项目背景。脱离背景讨论没有意义。
|
 |
TinkMay 27, 2015 via iPhone
73
我感觉要是业务需求每次都需要取整个detail的话，那这样倒也不失一种办法。当然是在不换数据库的情况下
|
 |
galenzhaoMay 27, 2015
74
对 nosql事务是个纠结的地方
好多业务逻辑 排除不掉事务。。。 不知道cto研究过SequoiaDB没 |
 |
feisanMay 27, 2015
75
建议大家看看7楼说的那篇文章，这样的设计也不是没有道理的。
另外mogodb这个东西，不要光顾着写代码用的爽，也要考虑一下运维的难度和成熟度。 |
 |
br00kMay 27, 2015
76
批量修改操作我想知道效率会怎样。。
|
 |
franksinMay 27, 2015
78
说说使用场景呗，有些特殊场景，kv也可能比较好用。
|
 |
ksupertuMay 27, 2015
79
现在的主流设计本来就不用数据库提供的外键啊，都是自己维护一套主外键代码
|
 |
michaelye1988May 27, 2015
80
我也是这样做的，我觉得很方便。现在接手的一个Android项目就遇到这个问题。服务端需要增加一个字段非常麻烦，客户端需要升级数据库。所以如果没有特别的需求，我觉得你们CTO做的没错。
|
 |
zongwanMay 27, 2015
81
|
 |
yuankuiMay 27, 2015
82
你确定你们的CTO不上v2ex吗？
|
 |
superisaacMay 27, 2015
83
这种用mysql作kv有个卵的性能。
为啥不用tokumx? |
 |
nino789pzwMay 27, 2015
84
@yuankui He's right there....
|
 |
arbipherMay 27, 2015
85
别撕了，别撕了，看新闻
MySQL 5.7.7 JSON labs release http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/ |
 |
shiznetMay 27, 2015
86
@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.持赞同 |
|
GG668v26Fd55CP5WMay 27, 2015 via iPhone
87
一开始我也准备喷为毛不用nosql，但看完了7楼的链接，我发现这样做还真有点道理，一种典型的用空间换时间的做法，充分利用了索引和MySQL较为成熟事务处理，可以做到快速查询跟安全存储，而且扩展性也不错。配合异步处理和自动化，就是一套完整的解决方案
|
 |
pubbyMay 28, 2015
88
看业务需要了，在一些业务需求多变的场合，当kv用，或者部分column当kv用有时候还是很方便的。
|
|
cevincheungMay 28, 2015
89
@kenken 事物指的不是单纯的操作成功，在事物过程中的其他计算才是最关键的。如果说表结构是类似这样：
users: id, detail orders: id, detail logs: id, detail 那为什么不干脆是一个表？或者有什么理由不去用mongodb？（事物不算，而且实现软事物并不难） |
 |
lyragosaMay 28, 2015
90
这种设计有好处有坏处
喷的人一定没遇到非常复杂的多层嵌套结构 当然你非要严格按照二范氏做他几十个表我也没办法反驳…… |
 |
JoeShuMay 28, 2015
91
以前做过类似的设计，不过稍有区别，就是要把索引字段需要抽取出来，不然性能会很差
优点很多： 1. 处理灵活，适合业务变化比较快的产品 2. 支持事物，适合对数据一致性要求高的场景 3. 支持行级锁，因为直到2.4版本，mongodb还只支持db级别的锁 4. mysql要比mongodb稳定的多，各种问题都有很成熟的解决方案 5. 很多云服务和运维服务不支持nosql。 6. 性能问题，mongodb对内存和磁盘空间的消耗实在是很大，尤其内存小于热数据的时候。 这种方案是综合了mysql和nosql的优点， 是一种很好的解决方案 |
 |
monkeylyfMay 28, 2015
92
也用过类似的schema设计 用postgres来实现 主要是为了灵活的应付需求改变 减少修改schema导致的db migration 稳定后的release的时候会把json里的数据拉出来当成col存
|
 |
deckenMay 28, 2015 via Android
93
postgrep大法好
|
 |
guotieMay 28, 2015
94
挺好。
我们在每个表里增加一个attr的字段，json结构，专门用来扩展。 |
 |
CharlesLMay 28, 2015
95
看V2的大侠们讨论，果然长知识.
|
Select Language