Skip to content

当数据库中已经存在某个词语或成语时,由于唯一约束的存在,其他用户尝试创建相同内容会遇到错误。 #3

@JJasonSun

Description

@JJasonSun

当前情况:

数据库表中词语/成语内容设置了唯一约束
用户A创建了"1234"这个词语
用户B看不到用户A创建的内容(权限隔离)
用户B尝试创建"1234"时会因为唯一约束冲突而失败

解决方案选项

方案1:前端预检查(推荐)

在用户提交创建请求前,先检查该词语是否已存在,如果存在则给出友好提示。

优点:

  • 用户体验好,提前告知冲突
  • 不需要修改数据库结构
  • 实现简单
  • 实现方式:

添加一个检查接口:GET /api/v1/ciyu/check?word=xxx
前端在用户输入完成后调用检查接口
如果已存在,显示提示:"该词语已存在,您可以查看现有内容或选择其他词语"

方案2:后端错误处理优化

改进后端的错误处理,当遇到唯一约束冲突时,返回更友好的错误信息。

优点:

  • 实现简单
  • 保持数据完整性

实现方式:

  • 捕获数据库唯一约束异常
  • 返回友好的错误信息,如:"该词语已存在,请尝试其他词语"

方案3:权限共享机制

允许用户查看所有系统中的词语,但只能编辑自己创建的。

优点:

  • 避免重复创建
  • 提高资源利用率
  • 用户可以学习其他人创建的内容

缺点:

  • 改变了当前的权限模型
  • 可能不符合某些使用场景的需求

方案4:用户命名空间

为每个用户创建独立的命名空间,允许不同用户创建相同名称的词语。

优点:

  • 完全隔离用户数据
  • 避免冲突

缺点:

  • 需要修改数据库结构(你提到不想动代码)
  • 可能导致大量重复数据

我的建议

考虑到你不想修改现有代码结构,我推荐 方案1 + 方案2 的组合:

前端预检查:提供更好的用户体验
后端错误优化:作为兜底机制
这样既保持了数据完整性,又提供了良好的用户体验。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions