关于数据库字段不允许重复的有关问题
关于数据库字段不允许重复的问题
假设现在有一张用户表,字段uuid是主键,另外有邮箱和手机字段,不是主键,但是也不能重复。
如果我在数据库里把邮箱和手机都设置为unique,经过测试,必须是两个字段都相同时,系统才认为是重复的。
也就是手机和邮箱假如只有一个重复,也是可以通过unique验证的。
假如在后台代码这里写逻辑判断是否重复,有可能发生两笔操作(即两个线程)同时在运行,无法检测互相之间是否有重复,这样也可以通过验证提交到数据库。
请问还有什么其他办法吗?
------解决思路----------------------
唯一约束,可以给单独一个字段设置,即表示在多条记录中,该字段的值不可出现重复。也可以设置多个字段组合起来要求唯一,即在多条记录中,不可出现多个字段值同时重复。设置方式如下:
创建表时设置:
创建表之后设置:
另外,对于缓存的,说下楼主说的系统复杂度和开销问题。对于系统复杂度来说,无非是多了缓存这一层。个人感觉没什么复杂的。对于系统开销来说,主要是看你的用户量或者说数据量。现在的硬件条件一般都支撑得起来。
至于数据库同步问题更不是问题。如果同步要求高的,可以先使用同步方式执行数据库插入。插入成功(无异常)后再执行缓存保存操作。如果同步要求不高的。可以采用异步方式执行数据库插入。再保存缓存。保存缓存后,异步插入数据库操作可能还没执行完,即可能出现插入异常后缓存已保存的情况。这时可以写个数据库操作回调。当失败时调用回调将对应缓存删除。
其实系统要采取什么方案,关键还是看你系统的业务需求。如果你的系统对响应要求比较高时,你所有查询操作都直接同步操作数据库的方式肯定是不可取的。而缓存这方面也主要是想解决数据查询的效率问题,是否需要用取决于你系统的业务需求。
假设现在有一张用户表,字段uuid是主键,另外有邮箱和手机字段,不是主键,但是也不能重复。
如果我在数据库里把邮箱和手机都设置为unique,经过测试,必须是两个字段都相同时,系统才认为是重复的。
也就是手机和邮箱假如只有一个重复,也是可以通过unique验证的。
假如在后台代码这里写逻辑判断是否重复,有可能发生两笔操作(即两个线程)同时在运行,无法检测互相之间是否有重复,这样也可以通过验证提交到数据库。
请问还有什么其他办法吗?
------解决思路----------------------
唯一约束,可以给单独一个字段设置,即表示在多条记录中,该字段的值不可出现重复。也可以设置多个字段组合起来要求唯一,即在多条记录中,不可出现多个字段值同时重复。设置方式如下:
创建表时设置:
CREATE TABLE `t_user` (
`Id` int(11) NOT NULL AUTO_INCREMENT, -- 自增
`name` varchar(50) NOT NULL unique, -- 唯一性约束
`phone` varchar(18) NOT NULL,
`mail` varchar(18) NOT NULL,
UNIQUE KEY (`phone`,`mail`), -- 联合唯一性约束
PRIMARY KEY (`Id`)
) ENGINE=InnoDB AUTO_INCREMENT=1018 DEFAULT CHARSET=gbk;
创建表之后设置:
ALTER TABLE `t_user` ADD UNIQUE KEY(`name`); -- 唯一约束
ALTER TABLE `t_user` ADD UNIQUE KEY(`phone`,`mail`); -- 联合唯一约束
另外,对于缓存的,说下楼主说的系统复杂度和开销问题。对于系统复杂度来说,无非是多了缓存这一层。个人感觉没什么复杂的。对于系统开销来说,主要是看你的用户量或者说数据量。现在的硬件条件一般都支撑得起来。
至于数据库同步问题更不是问题。如果同步要求高的,可以先使用同步方式执行数据库插入。插入成功(无异常)后再执行缓存保存操作。如果同步要求不高的。可以采用异步方式执行数据库插入。再保存缓存。保存缓存后,异步插入数据库操作可能还没执行完,即可能出现插入异常后缓存已保存的情况。这时可以写个数据库操作回调。当失败时调用回调将对应缓存删除。
其实系统要采取什么方案,关键还是看你系统的业务需求。如果你的系统对响应要求比较高时,你所有查询操作都直接同步操作数据库的方式肯定是不可取的。而缓存这方面也主要是想解决数据查询的效率问题,是否需要用取决于你系统的业务需求。