我应该如何构造我的数据库实体与邀请和收件人电子签名web应用程序？

Question

我有兴趣为我的电子签名web应用程序实现以下要求。

1. 用户可以创建新的签名契约。该合同可以包括多个用户签署。合同创建者需要提供收件人的电子邮件。每个收件人将有额外的数据分配，如签名细节，指示等。
2. 但是，被邀请的用户仍然不能出现在系统中。这是最棘手的部分。

现在，我的以下实现如下：

1. 我创建一个契约，然后通过通过电子邮件进行过滤来检查用户是否在系统中。如果用户存在，则使用带有附加数据的中间表创建多到多个实体ContractRecipientEvent，该表分配给契约。我创建它是多到多的，因为同一个用户可以被分配给多个契约。
2. 如果用户不在场，我创建邀请模型，设置所有收件人的特定数据，并发送电子邮件。然后注册用户，我使用该电子邮件运行所有邀请记录的查询，并通过从邀请模型复制数据创建ContractRecipientEvent。

我不喜欢我的方法有以下几点：

1. 多到多的领域。我只想为我的合同收件人使用普通的外键，但我不确定应该如何为同一合同分配多个用户？也许我应该用用户和契约创建一个新的ContractRecipient作为外键，但这也是一个多到多的字段吗？
2. 我不喜欢将数据从邀请模型复制到ContractRecipientEvent，只需要在用户注册之后才创建ContractRecipientEvent，因为我需要一个用户实体来创建一个ContractRecipientEvent，它对用户有一个外键。
3. 权限结构很难管理。我需要检查所有的用户，谁是包括在合同数据库记录，并检查他们是否被分配到合同id，他们正在使用的签名后的请求。

我正在附加合同列表的最后JSON代码。它可以工作，但我希望有一个正确的模型结构：

{
  "results": [
    {
      "id": 178,
      "is_author": true,
      "title": "ahhzhzh",
      "message_to_all_recipients": null,
      "contract_signing_status": "WAITING_FOR_ME",
      "contract_signing_type": "SIMPLE",
      "contract_signing_date": {
        "start_date": "2010-09-04T14:15:22Z",
        "end_date": "2010-09-04T14:15:22Z"
      },
      "recipients": [
        {
          "message": null,
          "recipient_signing_status": "NOT_SIGNED",
          "recipient_review_status": "NOT_REQUIRED",
          "recipient_action": "SIGN",
          "role": "ADMIN",
          "email": "test2331@gmail.com"
        },
        {
          "message": null,
          "recipient_signing_status": "NOT_SIGNED",
          "recipient_review_status": "NOT_REQUIRED",
          "recipient_action": "SIGN",
          "role": "BASE",
          "email": "test2333@gmail.com"
        }
      ]
    },
    {
      "id": 179,
      "is_author": true,
      "title": "dhhdhd",
      "message_to_all_recipients": null,
      "contract_signing_status": "WAITING_FOR_ME",
      "contract_signing_type": "SIMPLE",
      "contract_signing_date": {
        "start_date": "2010-09-04T14:15:22Z",
        "end_date": "2010-09-04T14:15:22Z"
      },
      "recipients": [
        {
          "message": null,
          "recipient_signing_status": "NOT_SIGNED",
          "recipient_review_status": "NOT_REQUIRED",
          "recipient_action": "SIGN",
          "role": "ADMIN",
          "email": "test123@gmail.com"
        },
        {
          "message": null,
          "recipient_signing_status": "NOT_SIGNED",
          "recipient_review_status": "NOT_REQUIRED",
          "recipient_action": "SIGN",
          "role": "BASE",
          "email": "test233@gmail.com"
        }
      ]
    },
 
  ]
}

Answer 1

首先，不要开始优化您的数据库模式或映像您可以偷工减料。尽量想出多少标准化的形式，这与您的业务领域最符合。错误建模以后会适得其反，最好从一开始就试着把模型做好。即使是像电子邮件这样的“自然主键”这样的小细节，当你开始考虑在图片中添加电话号码或一些硬件标记，或者你需要将用户合并为一个时，也会让人头疼。

第二，命名问题。例如，ContractRecipientEvent --给定这个名称，我想这是某种关于特定的合同接收者关系的日志条目。另外，收信人真的是好名字吗？也许，收货人是更好的吗？

1. 多到多的领域。我只想为我的合同收件人使用普通的外键，但我不确定应该如何为同一合同分配多个用户？也许我应该用用户和契约创建一个新的ContractRecipient作为外键，但这也是一个多到多的字段吗？

我想，在这里多对多是很自然的。根据您的其他用例，我甚至将所有契约签名元数据移动到一个表中，使关联表尽可能简单。仍然可以有一些整数状态字段，它可以提示进程执行的阶段，但是其他的东西都可以在其他地方，与此表相关。

也可能是，合同的收货人可以是一对多，但这样你就可以让收货人-用户有一个单独的多对一。也就是说，一份合同可以有2 (?)或者更多的签字人，每个用户可以是0到更多次(不同合同)的收货人。

因此，ContractSignee将使用契约id和用户id作为外键，以及一些id (如果您希望在一个单独的表中为每个收货人分配一些元数据)。看起来ContractSignee不仅仅是more关联表，因为它可以有一些有效负载(至少我从您的问题中理解了这一点)。

简而言之，ContractRecipient或更好的ContractSignee是个好主意。

我不喜欢将数据从邀请模型复制到ContractRecipientEvent，只需要在用户注册之后才创建ContractRecipientEvent，因为我需要一个用户实体来创建一个ContractRecipientEvent，它对用户有一个外键。

也许，用户在生命周期中可能有一些整数状态分配给他们？例如，"pending_verification“、”验证“、.、”删除“。在这里，保持实体简单，并将什么东西移动到一个辅助表也是很好的。这将帮助您有一个“坟墓”的用户，如果你需要一些分析以后。我还猜想，在电子签名应用程序中，审计跟踪必须有，甚至可能不像数据库中的日志那么简单，但您知道得更清楚。因此，每个实体甚至关系都可能有关联事件的日志表。

至于ContractRecipientEvent，如果你想要ContractSignee，我不知道你为什么需要这个。

权限结构很难管理。我需要检查所有的用户，谁是包括在合同数据库记录，并检查他们是否被分配到合同id，他们正在使用的签名后的请求。

ContractSignee可能是被指定为特定合同的收货人的唯一权威来源。拥有“未决”/“草稿”用户可能比在不同表中复制数据更不邪恶。而且，我认为同一个用户可以参与多个契约，因此ContractSignee与用户是完全独立的实体。可以让用户与ContractSignee相关联，从而提供对合同的访问。所有这些都可以在一个SQL查询中非常有效地完成。

这里还有另一个方面。今后，双方可能会以某种特定的顺序签订合同。这可能会影响对合同的访问，因此应该是结构的一部分。ContractSignee也可以具有某种状态，从这种状态可以很容易地判断收货人是否已经可以访问合同。

一般的建议是始终保持数据库模式的“主干”紧凑，将非键元数据移动到辅助表。

现在是关于邀请。从你的描述和其他评论中，我还不太明白这是必要的，所以我看到了两种情况：

1. 邀请函总是每一份合同。用户没有任何在系统内的身份，总是通过一次电子邮件链接或一些强大的认证认证；
2. 邀请始终是每个用户，来自您的系统，而不是特定的合同所有者。您的系统为用户提供身份验证的手段。

在第二种情况下，对于第一次用户来说，工作流可能是不同的，并且涉及到某些阶段上的签名，无论是单独的还是在传递到合同签署页面的。

Answer 2

1. 多到多的领域。我只想为我的合同收件人使用普通的外键，但我不确定应该如何为同一合同分配多个用户？也许我应该用用户和契约创建一个新的ContractRecipient作为外键，但这也是一个多到多的字段吗？

这一对多的关系实际上存在于您的域中(每个契约可以有来自多个用户的签名，每个用户可以对多个文档进行签名)。您可以尝试将其隐藏在您的模型中，但最有可能的是，您将限制您的用例太多，否则您将无法隐藏多到多性质的关系。

1. 我不喜欢将数据从邀请模型复制到ContractRecipientEvent，只需要在用户注册之后才创建ContractRecipientEvent，因为我需要一个用户实体来创建一个ContractRecipientEvent，它对用户有一个外键。

您可以通过对用户模型有两种不同的状态来避免复制:邀请状态和注册状态。然后，当您发现一个不存在的用户以签名者的身份添加到文档中时，您可以在被邀请状态下创建一个用户实例。这个被邀请的用户很可能还不能登录，或者做任何需要他们自己登录的操作，但是其他人应该可以引用他们(例如，将他们作为签名者添加到其他文档中)。

一旦用户遵循他们在邀请电子邮件中收到的链接，用户状态可以更改为已注册，并且可以填写在注册时提供的详细信息。

这意味着邀请模型只需要包含有关邀请本身的详细信息(邀请的用户、何时发送的电子邮件、应该遵循的链接等等)。

1. 权限结构很难管理。我需要检查所有的用户，谁是包括在合同数据库记录，并检查他们是否被分配到合同id，他们正在使用的签名后的请求。

这也是不可避免的，除非您给每个合同/用户组合一个独特的链接来添加他们的签名。然后，复杂性转移到链路生成。