适用于市场风格应用的用户数据库设计

Question

由于我是数据库架构的新手，因此需要一些最佳实践智慧。这适用于市场类型的应用程序。我喜欢的主要问题是处理用户。

我想要实现的是买方和卖方帐户共享登录/注册功能和一些特征，但卖方帐户有能力销售，接收付款等。买方可以发送请求，卖方可以完成它们。基本上卖方可以做买家可以做的一切，但另外查看和履行请求，并出售。

我会选择简单的角色，除了卖家在产品和付款信息方面的关系比买家更复杂。卖家也需要能够公开上市，并拥有公开的个人资料。我不确定拥有两个用户类型的大表将是理想的。

我目前的想法是在基本用户表和卖家表之间使用多态关联（也可能是买家特定的表）：

用户（买方）

• 名称
• 电子邮件
• encrypted_pa​​ssword
• （其他认证字段）
• 位置
• 占用
• meta_id
• meta_type

卖方

• 名称
• 位置
• 占用
• 等

请求（属于买方和卖方）

• 型
• 描述
• 完整
• buyer_id
• seller_id

产品（属于卖方）

• 描述
• CATEGORY_ID
• seller_id

正如您所看到的，一个重要问题是买家和卖家都有重复的数据。这是因为当我显示卖家时，我不想进行多表查询，但也许这不是问题？另一个选择是拥有用户基表，然后是买方和卖方表，但它们仍然包含重复信息。

向所有可能性开放..最好的方法是什么？

Answer 1

你听说过多态吗？

您可以创建一个“母亲”课程User（例如devise）并创建两个“儿童”课程Buyer和Seller！

好教程here

Answer 2

假设所有用户都是买家，但不是两者兼而有之，我会做以下事情，我认为这基本上就是你提出的建议：

PERSON   //我实际上有一个ROLE表，只在PERSON表中包含role_id但是除了复杂性之外可能不会添加任何内容，这取决于是否有关于要在db中存储的不同角色的数据

卖方 为person_id

买方 为person_id  //也许没有任何额外的买家数据，但是如果要实现数据库级别的外键约束，那么填充此表将允许您约束实际的买家

然后是附加表格。如果您使用外键约束来保证数据完整性，那么您将约束buyer_id＆amp; sell_id在特定的表（买方，卖方）上，它保证您不仅仅是限制PERSON。

如果人们既可以是买家也可以是卖家，那么我可能仍会使用此模型并拥有BUYER_AND_SELLER角色，但如果您确信这些是唯一的，可能最好将列is_buyer和is_seller添加到PERSON你将永远支持的角色。

Answer 3

您可以使用数据库超类型和子类型来表示此类关系。

对于您的示例，我将数据模型拆分为两组：用户和角色。角色可以是买方或卖方，用户可以拥有零个或多个角色。

然后我会创建以下逻辑实体来表示角色关系：

<强>超类型

• UserRole（此名称可能过于通用;我建议使用一个更能反映买方和卖方在您的应用程序中的角色的名称。）

<强>亚型

• 买家
• 卖方

对于您的物理设计，我建议使用以下设计之一：

1. 单个表，其中包含超类型实体的列以及每个子类型实体的列。检查约束可用于对子类型列强制执行非空约束。
2. 超类型的一个表，每个子类型实体都有一个单独的表。每个子类型共有的列存储在超类型表中，其他列存储在相应的子类型表中。将类型列添加到超类型表以指示实体的类型。每个子类型表都包含与超类型表的外键关系。
3. 混合方法，结合了上述每个设计的各个方面。

访问模式

在决定如何建模子类型和超类型关系时要考虑的一个因素是您的查询是否需要访问超类型和子类型表中的列。如果您的大多数查询都将访问超类型和子类型表中的列，那么单个表可能是更好的设计。

编辑 - 我建议使用第一种设计，除非有令人信服的理由为子类型创建单独的表。包含type列的外键可用于限制与特定子类型的关系。

将用户映射到角色

要将用户分配给角色，只需在User表和超类型（UserRole）表之间创建多对多关系即可。