这是一个创建于 3140 天前的主题，其中的信息可能已经有所发展或是发生改变。
通讯录应用用的较少，看到那种一大堆填表类型的就头大…… 比较喜欢 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 比较单纯，一般搜索联系人名和电话号码……
表达能力不太好 请见谅
由于经验较少，在遇到此类问题的时候，纠结过多！
问题 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 比较单纯，一般搜索联系人名和电话号码……
表达能力不太好 请见谅
 |
1
jsonline 2016-04-27 10:10:43 +08:00  1
你用 noSQL 不就好了……比如 MongoDB
|
 |
2
sun2920989 2016-04-27 10:12:07 +08:00 1
MongoDB+1
|
 |
3
JiShuTui 2016-04-27 10:13:59 +08:00 1
1 、账号表（ ID 、姓名）
2 、联系方式表（账号 ID 、联系方式类型、联系方式、备注） |
 |
4
XianZaiZhuCe 2016-04-27 10:14:50 +08:00 via iPhone 1
第一个问题，我选 c 。第二个问题，单独建立分组关系表。
一个姓名对应一个 id ，再拿这个 id 去建各种关系表，比如一个 id 好几个电话，好多分组关系 |
 |
5
yangqi 2016-04-27 10:17:25 +08:00 1
问题 1 肯定是用 C 啊， EAV 很常见，性能作为通讯率来说根本不用担心
|
 |
6
Mutoo 2016-04-27 10:31:00 +08:00 1
通讯录本身就是文档型数据， NOSQL 非常合适
|
 |
7
yeyeye OP @jsonline
@sun2920989 @Mutoo 通讯录只是这个程序中的一环（因为程序流程简单，很常用且用 like 匹配） 一下子换其他数据库不会用（没用过 noSQL 的）怕来不及鸟 谢谢 @JiShuTui @XianZaiZhuCe 谢谢 谢谢你们 我知道咋样选了 感谢~ |
|
8
sun2920989 2016-04-27 11:10:40 +08:00 1
@yeyeye 嗯 那就参考后面的几个回答,挺好的,只是觉得这种场景 MongoDB 挺适合的
|
|
9
yeyeye OP @sun2920989
因为目标是一个物流系统 流程简单 只是涉及到钱的处理会麻烦一点点 只用过 SQL 数据库做程序 虽然知道 noSQL 很棒 速度很强大 但是一下子怕用不来 所以不打算换了 以后学一下玩得转在用 嘿嘿！ |
|
10
yeyeye OP @sun2920989 主要是我目测了一下 根据业务量 几年内 SQL 数据库应该是顶得住的 如果还能做下去 那么到时候直接加大配置就好了 实在不行再慢慢优化 反正这种业务量不是那种非常大的顶得住
|
Select Language