基于角色的数据库设计。作为用户属性或角色特定表的角色

时间:2020-07-04 11:55:59

标签: postgresql database-design user-roles

我正在开发一个具有多个用户角色的Web应用程序。使用的数据库是Postgres10。角色非常不同,并且具有很多不重叠的数据,因此,通常一个特定的表应仅属于一个角色,而不属于另一个角色。

在下面的示例中,我将使用两个角色:卖方买方。第一个角色分配给拥有一些公司并销售商品的用户。第二角色分配给购买商品并可以收到礼物的用户。 卖方不能收到礼物,买方不能拥有公司。 卖方买方都可以有头像。

我正在考虑以下四种设计的优缺点。

案例1

case 1

这里我们有一个角色 reference table,它枚举了系统中的所有角色(卖方买方), user 表,其中包含引用角色表,头像 company gifts_recieved 表的用户的密码和用户电子邮件>用户表。

专业人士

  • 没有表具有可为NULL的属性

缺点

  • 应使用触发器来检查参照完整性。例如,如果具有 id = 1 user buyer ,则应防止在 company中插入一行表,其中包含 user_id = 1 。因此,我们应该在每个角色特定的表上创建一个触发器,该表引用 user 表以保护参照完整性。

案例2

enter image description here

此处, user 表包含可为空的角色属性: seller_id buyer_id (或示例中未包含的其他角色)。其中只有一个不是NULL,它定义了用户的角​​色。所有特定于角色的表都引用 seller buyer 表。这两个角色共有的 Avatar 表继续引用 user 表。

专业人士

  • 不需要触发器来保护特定于角色的表的参照完整性:它们都引用 seller buyer 表。

缺点

  • 可空值的角色属性。
  • 需要一个触发器(不是第一种情况下的所有表触发器),以确保仅角色属性( seller_id buyer_id )之一不为NULL,并且所有其他都是NULL。

案例3

enter image description here

为避免可空值的角色属性,我们将对表使用Postgres的inheritance(MySQL不支持此功能)。在这里, user 表被“吞噬”到 seller buyer 表中。 头像表已重复,并以角色名称作为前缀。

专业人士

  • 没有可空值的角色属性。
  • 完全没有触发器。

缺点

  • 用于不同角色的表是重复的,这纯粹是浪费资源。
  • 继承是Postgres特有的功能。

案例4

enter image description here

为解决案例3中的重复问题,将 avatar_id 移到 user 表中,卖方买方继承。因此,对于卖方买方公用的每个表,我们都将为其父表( user )添加一个属性。

专业人士

  • 没有触发引用完整性的条件
  • 没有表重复
  • 没有NULL形容词

缺点

问题

以上哪种解决方案适合最佳数据库设计实践(如果有)?用户角色应该是用户表的属性还是特定的表?

说明

  1. 卖方只能拥有一个公司。
  2. 通过电子邮件/密码对标识的用户可以是卖方或买方。

1 个答案:

答案 0 :(得分:1)

我偏爱案例2。

由于使用继承,我不会考虑案例3和4。我已经多年没有访问过这个主题了,但是我最大的担忧是使用数据库实现继承的开发人员是否能够将他们的思想集中在如何使用它上。

触发器是我脑海中案例1的症结所在。

您是否知道案例2中不需要触发器?

0x7ffff7f7b1ac
相关问题