微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

在 SQL 中建模用户和角色的正确方法 数据模型注意

如何解决在 SQL 中建模用户和角色的正确方法 数据模型注意

我正在设计一个 Java 应用程序,模型数据存储在 Oracle sql Server 中。我正在尝试根据需要设计最佳用户/角色模型。

由于业务规则,所有用户都有基本的共同信息:

  • 身份证件
  • 姓名
  • 姓氏
  • 电子邮件
  • IsActiveUser

但是根据角色,用户将有额外的字段,例如:

客户角色:

  • 出生日期
  • 地址

律师角色:

专家角色:

  • 职业

经理角色:

  • 地区

我认为有两种可能的解决方案:

  1. 用户表将包含所有通用字段和将根据角色填充的可选字段。
  2. 用户表将只有常用字段,然后我创建了一个 Detail_User 表来保存随角色变化的可选字段。

您认为这种可能的解决方案好吗?有没有更好的替代解决方案?

解决方法

在关系数据库范式中回答,正如您所标记的那样。

您认为这种可能的解决方案好吗?有没有更好的替代解决方案?

没有。这是子类型的经典案例。

我有一个角色表,用户表有一个 FK,因为每个用户都只有一个角色。

那不能解决你的问题。您需要存储角色的每个实例、用户的每个实例的值。

此外,只有当您希望将某些子表(例如 Portfolio.LawyerId)限制为 Lawyer 而不是 User 时,您才会欣赏正确的解决方案。

数据模型

IDEF1X/ER 级别(非 ERD)中的数据模型是:

User Role Data Model

注意

  • 自 1983 年以来的关系数据建模标准是 IDEF1X。对于那些不熟悉标准的人,请参阅简短的 IDEF1X Introduction
  • 有关子类型的完整定义和使用注意事项,请参阅Subtype Definition
,

除非您将拥有无数行,否则无需将表拆分为您指定的两个。

可能为每个角色考虑一个单独的表——或者更具体地说,为每个具有定制列的角色。在许多情况下(相对于 NULL),这会在更广泛的记录中为您提供一点存储空间效率,尽管这取决于所使用的数据库和数据类型。

拆分它们的一个更重要的原因是外键引用。如果您有其他表,其中“律师”将是外键,那么您需要一个 lawyers 表。瞧!为不同的角色使用单独的表允许此类专用关系以及所有用户的通用关系。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。