目前想到 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 比较单纯，一般搜索联系人名和电话号码……