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

通讯录应用用的较少，看到那种一大堆填表类型的就头大…… 比较喜欢 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 比较单纯，一般搜索联系人名和电话号码……


表达能力不太好 请见谅