V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
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
sinux
V2EX  ›  MySQL

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

  •  1
     
  •   sinux · 2015-05-27 11:04:43 +08:00 · 12100 次点击
    这是一个创建于 3480 天前的主题,其中的信息可能已经有所发展或是发生改变。
    detail是一个json字符串。

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

    他说这样可以避免外键的混乱和冲突,自己来维护外键关系。
    115 条回复    2015-06-07 16:40:25 +08:00
    1  2  
    feisan
        101
    feisan  
       2015-05-28 10:41:23 +08:00
    @shiznet 恩,我同意你的观点。没错,现在多了很多选择。不过从运维的角度看,MySQL的成熟度是更高的,各种优化、扩展、备份方案都很成熟,熟练的工程师也好找。相对而言,比较新生的一些数据存储服务,在这些方面有待发展。所以我会觉得这个CTO采用这样的方案也是可以理解的。
    kenken
        102
    kenken  
       2015-05-28 10:42:24 +08:00
    @est 头像都存到数据库吗?。。 小规模用图片服务器,大规模直接分布式dfs之类。 而且业务检测是肯定要做的,要不然就是bug了。
    lawmil
        103
    lawmil  
       2015-05-28 11:08:00 +08:00
    哎..我只想说一句..你们大城市人真会玩!
    aksoft
        104
    aksoft  
       2015-05-28 13:58:50 +08:00
    哎..我只想说一句..你们大城市人真会玩!
    cloudop
        105
    cloudop  
       2015-05-28 15:07:01 +08:00
    我就问索引怎么办吧?
    cloudop
        106
    cloudop  
       2015-05-28 15:15:28 +08:00
    除非你们的业务需求非常的特别,并且有一中间层来处理协同程序员和数据库(用mysql这不脱裤子放屁么,用其它类型数据库不好么)。再说了,查询字段,统计加加减减的怎么弄?中间层写不清楚,无数bug出来。开发的时候那坨json里面的字段谁都可以加新字段,有的记录detail有这个字段,有的没有。我去,这想想就带感。
    cloudop
        107
    cloudop  
       2015-05-28 16:35:50 +08:00
    认真的看了下kenken的发言和7楼的文章,认真想想发现挺颠覆的。我们是做手游的,服务端的部署很麻烦,特别是加新功能动到表结构的时候,要每一服都同步表结构,很是头疼。这种结构很有启发。
    sampeng
        108
    sampeng  
       2015-05-28 17:24:10 +08:00
    这个方案没问题啊。。。只是颠覆常规思维而已。。
    只是这样考虑的问题要多一点。。。
    我个人比较在乎的速度。。一个json里面东西多了还是蛮带感的。拉一个列表拉一堆无用的东西出来。
    但是如果有个中间层,这就不是问题。如果没有。。。还是别这么玩好,量上去了。速度问题很难优化。
    sampeng
        109
    sampeng  
       2015-05-28 17:31:00 +08:00
    我刚还想,为啥不redis。。。
    如果没有事务要求,redis比mysql更适合一点。
    mongo就太重了。。mongo其他组用过,后来出各种奇葩问题。就不怎么用了。。。
    txlty
        110
    txlty  
       2015-05-28 18:01:20 +08:00
    怎么没人说是为了将来在各种数据库之间平稳过渡、自由选择?
    改个配置参数,就切换一种数据库。这也挺酷炫的。
    jasonding
        111
    jasonding  
       2015-05-28 18:05:42 +08:00
    坐等 CTO 发帖
    sampeng
        112
    sampeng  
       2015-05-28 18:06:39 +08:00
    @txlty 炫酷啥。。99%的公司项目是不需要这样的。。
    况且切换数据库没那么简单。。。数据同步,停服务还是热切换。。我觉得所谓改个配置参数就切换数据库。纯粹是臆想。。
    cjyang1128
        113
    cjyang1128  
       2015-05-28 18:29:01 +08:00
    坐看各位大侠撕逼
    kenken
        114
    kenken  
       2015-05-28 18:31:36 +08:00
    其实还有一点是,不是每个detail都存储所有的信息。detail是按照业务纬度划分的,各业务关注的纬度也是不一样的。 每次load不需要load所有detail,只需要load和更新它关注的那一条数据就可以了。

    detail的json也是不能无限制增长的,一般我们使用text,65535的长度是完全够用的。 这样给上层带来的灵活度是很不错的。

    当然根据不同的业务场景设计肯定是不同的,这个是要灵活配置的。
    mingyun
        115
    mingyun  
       2015-06-07 16:40:25 +08:00
    基于什么考虑
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3634 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 868ms · UTC 04:24 · PVG 12:24 · LAX 20:24 · JFK 23:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.