如何处理多态关联案件

问题描述

在我们的应用中，多种类型的用户（企业客户，标准客户，公司员工，工人）可以在“客户支持”页面上打开故障单。创建新票证时，它应具有Author属性。现在，我想到了三种方法来设计解决方案：

具有针对每种类型的用户的常规“ Users”表和许多子表，以及一个引用常规“ Users”表的常规“ Tickets”表和“ author_id”字段。
```
Tickets: ticket_id (PK) | author_id (FK)
```

每种类型的用户都有单独的独立用户表，每种类型的用户凭单（公司客户凭单，标准客户凭单，公司员工凭单，工人凭单）都有通用的“ Tickets”表和许多子表。与一对多关系的用户表：

Tickets: ticket_id (PK) | (other ticket data fields...)

CorporateClientTickets: ticket_id (PK,FK) | corporate_client_id (FK)

StandardCustomerTickets: ticket_id (PK,FK) | standard_customer_id (FK)

CompanyEmployeeTickets: ticket_id (PK,FK) | company_employee_id (FK)

WorkerTickets: ticket_id (PK,FK) | worker_id (FK)

每种类型的用户都有单独的独立用户表，而常规的“ Tickets”表则具有多个空字段，例如每种类型的用户都可以使用“ NULL”字段，例如“ corporate_client_id”，“ standard_customer_id”，“ company_employee_id”，“ worker_id”，并根据其中一种填充到票证作者的类型，并将其他人保留为NULL。
```
Tickets: ticket_id (PK) | corporate_client_id (FK) | standard_customer_id (FK) | company_employee_id (FK) | worker_id (FK) | (other ticket data fields...)
```

我想知道您的方法以及您的方法的“原因”。

编辑：当前，票证类型之间没有不同的列，所有列都应有票证ID，作者ID，标题和状态（打开或关闭）。

解决方法

没有进一步了解您打算如何使用数据以及应用于用户和票证的不同业务规则。没有这个，我提供第四种选择。一个用户表，一个带用户FK的票证表和一个指示票证类型的类型代码。鉴于所提供的信息有限，这是最简单，最灵活的组织。真正的问题是每个表还包含哪些其他列以及预期用途。简而言之，您可能需要考虑的不仅是PK，FK，而且还有更多。

database-design polymorphic-associations