针对特定场景的 CRM 用户表的数据库设计答案

【问题标题】：Database design for CRM User table for a specific scenario针对特定场景的 CRM 用户表的数据库设计
【发布时间】：2017-12-17 07:18:23
【问题描述】：

我正在为我们的 CRM 系统设计一个数据库，需要一些有关 CRM 用户表的帮助。

用户类型：

管理员
分公司 2 的销售代表
分公司 3 的销售代表
客户端登录

现在对于这种情况，将所有用户放在一个表中并使用名为“type”的表属性来标识用户类型是否有意义？或者我应该为每种类型的用户设置一个单独的表格吗？此外，销售代表之间还会分享一些信息。

【问题讨论】：

您能提供更多信息吗？目前，这个问题很模糊。

标签： sql database database-design crm

【解决方案1】：

通常情况下，我通常会使用一张 User 表和与之关联的 Type。如果您有其他要存储的销售代表属性，请创建一个 SalesRep 表，并将外键返回到 User 表。然后，创建一个连接 User 和 SalesRep 的视图，这样从逻辑上讲，它看起来就像只有一个 usvSalesRep 表，其中包含销售代表所需的所有属性。

但是，这在很大程度上取决于数据量和事务负载，因此您可以提供的其他信息很有用。

【讨论】：

用户少于 100 人，每天少于 1000 笔交易。 SalesRep 将具有一些额外的属性，例如他们在某年完成了多少销售，有多少出价，基本上还有一些性能属性。
@mvador99 - 单表可以满足您的需要，没有问题，然后:)
这些表的外键，反之亦然:)

【解决方案2】：

这取决于您期望的用户数量。

但通常一个表就足够了。

如果您将拥有数十亿用户，也许您可以使用horizontal partitioning 并制作多个表格。

【讨论】：

不到 1000 个用户。我猜是单桌。谢谢！

【解决方案3】：

单桌应该没问题。我不同意在这种情况下，用户数量确实对其设计有很大影响。

只要有可能，您应该设计您的表格以模仿现实生活。管理员、销售代表等只是他们是谁的描述/属性。最终，他们都是“人”……或用户。因此，拥有一个带有“Admin”、“SalesRep”作为属性的“User”表对我来说很有意义。仅当用户只能是一种“类型”时才使用“类型”方法。如果它们可以是多个用户类型，请使用单独的列。 IE。一个可以同时是 SalesRepBranch2 和 SalesRepBranch3。可能会考虑进一步规范化这一点。

【讨论】：