微信（QQ）重名困扰探究系列之一数据库设计与SQL模糊查询

**徐文艺    写于2022.2.15（农历正月十五）**<br/>转载请注明出处（由于文章在本人智能手机书写，同时仅分析，无法附具体图片，仅文字）联系QQ:286902544
最近偶尔听到有人在说**重名**，就翻了下记忆中基于标准SQL的一些处理，下面简单从系统数据结构设计和标准SQL模糊查询实现两个角度分析。

一、系统数据结构设计

其实系统数据结构设计和SQL查询并无直接关系，但却决定模糊查询时的操作处理。
先提出问题，举个例子：
***现在大家都用微信，也有人用QQ，那么微信和QQ是如何建立强关联关系的呢？这个问题其实就是系统数据结构设计时冗余字段或关联（子）表设计的问题。如果没有手机号码或电子邮箱的实时应急措施，那么上面的问题核心就归类到我们这次要讨论的主题，系统数据结构设计和标准SQL模糊查询。***
下面我们尝试用稍专业角度结合技术分析，尽量少用技术术语。
个人微信社交好友列表中每个好友都有名称、账户号、备注，而我们也可以针对每个好友设置不同的昵称（姓名）、备注等（好友的账户号我们无法修改），这是我们私人手机微信账户针对好友的行为（和对方没任何关系），和我们的微信好友的实际名称、备注没关系，可以一样也可以不同。当然好友也可以在他的手机上同样操作。

从技术实现上说，具体数据结构设计下面2个表格（由于是社交软件，最简化分析仅2个表格，其余根据不同业务不同设计方案单独列出，与真正的办公ERP/OA系统的用户账户的岗位等不同，这里也不涉及）。
先说明下唯一标识的实现方式，目前主流主要有2种，一种采用数字自动增长的方式实现即序列sequence（关于位数对齐等这里也不讨论），另一种是使用至少16位的包含拼音和数字的唯一UUID实现。至于其它的实现方式暂不讨论。
第一个表就是用户表，主要是每个人的唯一标识ID、账户号、手机号码、账户名称、昵称、备注、备用列等。第二个表就是社交好友列表即通讯录，用于存每个人的通讯录的好友数据，具体内容根据下面2个方案略有不同。

方案1 冗余表数据结构设计
第二个表，主要是数据唯一标识ID、个人唯一标识ID（可设为外键，也可不设）、好友唯一标识ID（可设为外键，也可不设）、好友账户号、好友账户名称、好友昵称、好友备注、备用列（可能有多个）等。
方案2 关联表数据结构设计
第二张表：主要是数据唯一标识ID、个人唯一标识ID（可设为外键，也可不设）、好友唯一标识ID（可设为外键，也可不设，同样是第一个表中数据）。
***数据结构设计结束语
第一种情况，当然后面的几列从好友账户号列到备用列可能会有出入，但列数的多少并不影响整体意思的表达，只要包含一个和第一个表的列相同，我们就可以称这是冗余表数据结构设计。
第二种情况，关联关系表的设计思路比较简单，这也是大部分主流账户系统通用的解决办法。当然这种设计会引发另外一个问题（单向即对方是你的好友而你不是对方的好友/双向即双方互为好友），这里不展开说。
可能写到这里很多人已经明白我提出的问题的意思了。
如果是第二种方案设计，那么目前微信的好友的昵称和备注等就无法处理。QQ毕竟历史悠久，基本不存在这个问题，但目前看问题并不这么简单，个人感觉可能是早期微信用户扩张期的用户来源直接从QQ转（应急的手机号/电子邮箱登录）导致，不过不能一概而论。

二、标准SQL数据模糊查询

我们不基于具体关系型数据库讨论（Oracle、SQL Server、Mysql、DB2等），只要是符合标准92SQL的关系型数据库均可。
针对上面分析的简单数据结构设计，核心表中有3～5列，分别为账户号、账户名、昵称、备注等。
第一种基于同一个数据库同一个表同一列进行模糊查询，分别为左侧模糊、右侧模糊、全文模糊。

***左侧模糊***主要是尾部的字固定，头部内容模糊查询，具体类似如下：
微信服务端库.第一个表.昵称 like ‘%X’
微信服务端库.第一个表.备注 like ‘%X’
本地库.第一个表.昵称 like ‘%X’
本地库.第一个表.备注 like ‘%X’。
结果比如2个人的微信自己设置的昵称分别为张三/张某三，那么这种方式下仅查询三可能就串了，就是我们目前说的重名了一样。如果智能拼音查询的话串的概率就更高了。
***右侧模糊***主要是头部的字固定，尾部内容模糊查询，具体类似如下：
微信服务端库.第一个表.昵称 like ‘X%’
微信服务端库.第一个表.备注 like ‘X%’
本地库.第一个表.昵称 like ‘X%’
本地库.第一个表.备注 like ‘X%’。
结果比如2个人的微信自己设置的昵称分别为张三/张三丰，那么这种方式下仅查询张三两个人可能就串了，如果账户名、昵称、备注类似例子中就是我们目前说的重名了一样。如果智能拼音查询的话串的概率就更高了。
***全文模糊***主要是列内容模糊查询，具体类似如下：
微信服务端库.第一个表.昵称 like ‘%X%’
微信服务端库.第一个表.备注 like ‘%X%’。
本地库.第一个表.昵称 like ‘%X%’
本地库.第一个表.备注 like ‘%X%’
第二种基于不同列的模糊关联，主要分为基于冗余字段的多表单（多）库模糊处理和基于关联方式的单表单（多）库模糊处理

首先明确，当前用户的唯一标识ID其实就是微信的账户号，目前就是一年只允许修改一次的那个。正常来说用户唯一标识ID一般系统自动生成，就是文章开头介绍的至少16位的一堆拼音数字组合。而账号就是各家网络互联网公司的入口注册的在其系统中的唯一标识账户号，不能重复，和账户名称、昵称等不是一个概念。

基于冗余方式的多表单库模糊处理，比如2个人的微信自己设置的昵称分别为张三/张三丰，备注分别是张三/张三丰，那么这种方式下仅查询张三两个人可能就串了，如果账户名是昵称，昵称、备注相同就是我们目前说的重名了一样。如果智能拼音查询的话串的概率就更高了。
模糊查询如下：
微信服务端库.第一个表.ID=当前登录用户唯一标识ID
当前登录用户正在修改的好友唯一标识ID=微信服务端库.第二个表.好友唯一标识ID
微信服务端库.第一个表.昵称（备注）=微信服务端库.第二个表.备注（昵称）
微信服务端库.第一个表.昵称（备注） like ‘%X%’ 。
或者
本地库.第一个表.ID=当前登录用户唯一标识ID
当前登录用户正在修改的好友唯一标识ID=本地库.第二个表.好友唯一标识ID
本地库.第一个表.昵称（备注）=本地库.第二个表.备注（昵称）
本地库.第一个表.昵称（备注） like ‘%X%’

基于关联方式的单表单库模糊处理，比如2个人的微信自己设置的昵称分别为张三/张三丰，备注分别是张三丰/张三，那么这种方式下仅查询张三两个人可能就串了，如果账户名是昵称，昵称、备注相同就是我们目前说的重名了一样。如果智能拼音查询的话串的概率就更高了。
模糊查询如下：
微信服务端库.第一个表.用户标识ID（账户号）=当前用户的唯一标识ID（当前用户账户号）
微信服务端库.第一个表.用户唯一标识ID=微信服务端库.第二个表.个人（好友）唯一标识ID
微信服务端库.第一个表.昵称=微信服务端库.第一个表.备注
微信服务端库.第一个表.昵称（备注） like ‘%X%’
或者
本地库.第一个表.用户唯一标识ID（账户号）=当前用户的唯一标识ID（当前用户账户号）
微信服务端库.第一个表.用户唯一标识ID=本地库.第二个表.个人(好友)唯一标识ID
本地库.第一个表.昵称=本地库.第一个表.备注
本地库.第一个表.昵称（备注） like ‘%X%’
**
————————全文结束———————————

上面文章仅限于分析目前我个人（可能好多人和我一样也碰到过）使用微信或QQ中碰到的问题，比如你的微信/QQ中想修改好的名称（备注），发现无论如何都没法修改等。
和腾讯公司的实际技术没任何关系，仅个人的技术分析猜测结论。文章写的比较仓促，里面有部分内容未必准确，里面的名字是随口起，和现实任何人没关系。