V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
yeyeye
V2EX  ›  问与答

通讯录类字段数量不规律的情况如何设计数据库

  •  
  •   yeyeye · 2016-04-27 09:44:32 +08:00 · 2023 次点击
    这是一个创建于 3123 天前的主题,其中的信息可能已经有所发展或是发生改变。
    通讯录应用用的较少,看到那种一大堆填表类型的就头大…… 比较喜欢 Gmail 的通讯录 要什么字段自己选 很多样化!
    由于经验较少,在遇到此类问题的时候,纠结过多!


    问题 1
    我的某个人的通讯录是这样的
    电话号码 4 个 可以标注不同的名字 还可以自定义字段(资料的字段名称 [比如如果选项里不能填写身高,就可以自己定义一个身高选项,以此类推] )
    而大部分情况,一个联系人就一个电话和名字

    现在自己的应用也要有通讯录这个功能,所以很想使用 Gmail 的这种类型,因为设计好之后就很少需要修改了

    目前想到 3 个方案
    A 通讯录表下面建立很多个字段,比如电话号码就建 8 个字段,你总不可能记录超过 8 个电话号吧,其他字段预留一大堆
    B 通讯录下每种类型建立一个字段 用 json 或其他自定义格式存储
    C 专门建立一个表 随便自定义名称(字段),和 Wordpress 一样,一个字段记录联系人 ID ,一个记录字段名,一个记录值

    AB 方法都有一个毛病,就是 SQL 不好写!!!
    C 的 SQL 很好写!(比如要被其他表关联的时候,比如要 like 搜索的时候)
    至于性能 不知道哪个好,完全匹配我猜是 C 更快,不完全匹配 AB 方法估计都会蛋疼,而且 AB 很不好匹配

    问题 2
    A 联系人分组,有的时候一个联系人可能是和多个分组都有关联的,想放到多个分组里面,和文章管理类型的程序是不是有点像?有时候想放到多个分类里。
    B 这样就产生了上面的问题,到底是用一个字段直接记录多个分组 ID ,还是专门建立个表,专门来存放用户的分组关系?每个分组+联系人 ID 一条记录……(其他没有此类烦恼的字段不单独建表)
    同样的也是和上面一样, A 方案写 SQL 会蛋疼, B 方案写 SQL 很方便,性能不知道……

    问题 3
    不问场景只问方案不妥 实际是这样的 以上情况 精确匹配是经常要用的 很多地方都可能用到 like 匹配用于搜索联系人 也是很常见的 但是 like 比较单纯,一般搜索联系人名和电话号码……


    表达能力不太好 请见谅
    10 条回复    2016-04-27 11:18:42 +08:00
    jsonline
        1
    jsonline  
       2016-04-27 10:10:43 +08:00   ❤️ 1
    你用 noSQL 不就好了……比如 MongoDB
    sun2920989
        2
    sun2920989  
       2016-04-27 10:12:07 +08:00   ❤️ 1
    MongoDB+1
    JiShuTui
        3
    JiShuTui  
       2016-04-27 10:13:59 +08:00   ❤️ 1
    1 、账号表( ID 、姓名)
    2 、联系方式表(账号 ID 、联系方式类型、联系方式、备注)
    XianZaiZhuCe
        4
    XianZaiZhuCe  
       2016-04-27 10:14:50 +08:00 via iPhone   ❤️ 1
    第一个问题,我选 c 。第二个问题,单独建立分组关系表。
    一个姓名对应一个 id ,再拿这个 id 去建各种关系表,比如一个 id 好几个电话,好多分组关系
    yangqi
        5
    yangqi  
       2016-04-27 10:17:25 +08:00   ❤️ 1
    问题 1 肯定是用 C 啊, EAV 很常见,性能作为通讯率来说根本不用担心
    Mutoo
        6
    Mutoo  
       2016-04-27 10:31:00 +08:00   ❤️ 1
    通讯录本身就是文档型数据, NOSQL 非常合适
    yeyeye
        7
    yeyeye  
    OP
       2016-04-27 10:59:44 +08:00
    @jsonline
    @sun2920989
    @Mutoo

    通讯录只是这个程序中的一环(因为程序流程简单,很常用且用 like 匹配) 一下子换其他数据库不会用(没用过 noSQL 的)怕来不及鸟 谢谢


    @JiShuTui
    @XianZaiZhuCe
    谢谢


    谢谢你们 我知道咋样选了 感谢~
    sun2920989
        8
    sun2920989  
       2016-04-27 11:10:40 +08:00   ❤️ 1
    @yeyeye 嗯 那就参考后面的几个回答,挺好的,只是觉得这种场景 MongoDB 挺适合的
    yeyeye
        9
    yeyeye  
    OP
       2016-04-27 11:14:49 +08:00
    @sun2920989
    因为目标是一个物流系统 流程简单 只是涉及到钱的处理会麻烦一点点 只用过 SQL 数据库做程序 虽然知道 noSQL 很棒 速度很强大 但是一下子怕用不来 所以不打算换了 以后学一下玩得转在用 嘿嘿!
    yeyeye
        10
    yeyeye  
    OP
       2016-04-27 11:18:42 +08:00
    @sun2920989 主要是我目测了一下 根据业务量 几年内 SQL 数据库应该是顶得住的 如果还能做下去 那么到时候直接加大配置就好了 实在不行再慢慢优化 反正这种业务量不是那种非常大的顶得住
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3619 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 04:33 · PVG 12:33 · LAX 20:33 · JFK 23:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.