唯一性判断应该由数据库唯一索引来决定，还是由service层写代码进行判断？这么决策的原因是什么？

[圣殿骑士18]

最近在写nodejs服务端，看到别人的代码，在代码中进行唯一值的判断，又勾起了我的回忆。

因为我在以前做的C#项目中，是使用数据库的唯一性索引来实现报错的。因为受不了重复的冗余的代码验证（即数据库层已经能验证，为什么还要写代码再验证一次），所以，我在C#中，是通过捕捉数据库表的唯一性索引报告的异常，再进行统一处理来报错的。

现在，我又看到nodejs代码写成这样，看着这啰嗦的验证逻辑，又产生了cut掉它的冲动。

该不该在service端，保留唯一性校验的代码逻辑？如果保留，考量的原因是什么？

附代码：
js的，由代码进行唯一性验证



C#，捕捉数据库异常实现（try catch）
代码略

[娃都会打酱油了]

唯一性约束肯定做在数据库，至于你业务层要不要做唯一判断随便你，但业务中判断唯一肯定会存在多线程问题

[XBodhi.]

推荐先查询后，在做其他操作，否则会产生日志

[圣殿骑士18]

引用 2 楼 XBodhi. 的回复:

推荐先查询后，在做其他操作，否则会产生日志

日志问题可以解决。因为写入日志的逻辑，也是自己写的代码。那么如果是唯一索引冲突异常，就不记入错误日志。

[圣殿骑士18]

引用 1 楼 娃都会打酱油了 的回复:

唯一性约束肯定做在数据库，至于你业务层要不要做唯一判断随便你，但业务中判断唯一肯定会存在多线程问题

是的，业务中的多线程问题，还要数据库端有一种机制来实现。记得EF里是有这种支持的，原理就是更新时和读取标记比较，如果读取标记被修改，则保存失败。
而如果使用数据库索引来约束，那就没这些繁琐的事情了。
但这样，会不会带来性能的下降？比如异常处理流程可能会比较慢，数据库错误的处理流程效率怎么样？