database-design - 我应该如何在单独的成员(member)提供者中保持对用户的参照完整性？

Question

如果我有一个单独的成员资格提供商 API，它不在我的数据库中存储凭据和角色，我应该如何通过我的应用程序对用户的引用来维护引用完整性？

例如，我们与成员(member) API 交互，但向其传递成员(member)名称并基本上请求访问配置文件或角色，但我无权访问底层数据库。

然后我们可以使用返回的角色或配置文件来控制应用程序内的访问。这种方法的问题在于，当我们保留有关该用户操作的信息(例如记录他们的更改或工作流中的任务分配)时，我们会存储来自提供商的用户 ID，但由于该信息不在我们的应用程序数据库中，我们不能 FK 到它具有数据库完整性。

而且，实际上，这是有道理的，因为成员(member)提供者没有与我们签订契约(Contract)来确保他们的更改不会违反我们应用程序数据库中的 FK。

但似乎我应该能够按用户在我自己的应用程序数据库中聚合信息，或者有东西来强制引用我持久的用户 ID。

我正在考虑一个单独的“瘦”用户表，其中包含一些定性信息，例如来 self 们的提供商的姓名和 ID...该表可能会在首次登录时填充。

好处是我现在可以仅在我的应用程序中根据一些用户信息聚合用户信息，并且我可以在我的应用程序数据库中强制执行引用。缺点是我正在复制用户数据，这可能已经过时了。

Answer 1

这个问题实际上是关于两个不同的事情。

1. 远程数据库的外键是否也应该是本地表的外键。
2. 你能保持对外部数据库的参照完整性吗

这是完全不同的两件事，尽管对两者的快速回答实际上是一样的:

没有。

但让我详细介绍一下。

<强>1。使用远程数据库的外键

为了减少对远程数据库的依赖，您应该只将这些外键存储在数据库中的一个位置。

示例:假设您有一个博客，用户可以在其中发表评论。这些用户将通过 Facebook 登录。您现在拥有一个远程数据库 (Facebook) 和一个存储用户评论的本地数据库。您现在可以遵循以下两种设计之一:

• comments 表，将 facebook_id 存储为外键

或

• 一个单独的 users 表存储 facebook_id 以及一个本地 id 和一个使用您的 comments 表本地 ID 作为外键。

您不应该在两者中使用 facebook_id。虽然这实际上可行，但您在不需要的情况下引入了对远程数据库的依赖。您将无法添加来自非 Facebook 用户的评论，因为这会破坏您的设计。

2.远程数据库的引用完整性

您可能不打算问这个问题，但术语参照完整性 意味着远程数据库的所有外键实际上都引用了现有的远程记录(即用户)。保持完整性的唯一方法是远程数据库通知您远程记录的更改或删除，但通常情况并非如此。

示例:让我们回到上面提到的假设博客。一些 Facebook 用户发表了评论。后来同一个人决定删除他们的 Facebook 帐户。 Facebook 数据库可能不会通知您发生了这种情况，从而在您的数据库中留下“死”记录，这些记录不再链接到远程数据库中的有效记录。这破坏了参照完整性。因此，除非您有真正维护完整性的好方法，例如接收删除通知等，否则您应该设计您的应用程序，以便在 Facebook 用户被删除时它不会中断。