如果我有一个单独的成员资格提供程序 API，它不在我的数据库中存储凭据和角色，我应该如何维护应用程序对用户的引用的引用完整性？
例如，我们与成员 API 接口，但向其传递成员名称，基本上请求访问配置文件或角色，但我无权访问基础数据库。
然后，我们可以使用返回的角色或配置文件来控制应用程序中的访问。这种方法的问题在于，当我们保留有关该用户操作的信息（例如记录其更改或在工作流中分配任务）时，我们会存储来自提供商的用户 ID，但由于该信息不在我们的应用程序数据库中，因此我们无法 FK 到它具有数据库完整性。
而且，实际上，这是有道理的，因为成员资格提供商没有与我们签订合同，以确保他们的更改不会违反我们应用程序数据库中的 FK。
但似乎我应该能够按用户在我自己的应用程序数据库中聚合信息，或者有一些东西来强制对我的持久用户 ID 进行引用。
我正在考虑一个单独的"瘦"用户表，其中包含一些定性信息，例如我们提供商的名称和 ID......此表可能会在首次登录时填充。
好处是，我现在可以仅在应用程序中针对某些用户信息聚合用户信息，并且可以在应用程序数据库中强制实施引用。缺点是我正在复制用户数据，这可能是过时的。
这个问题实际上是关于两件不同的事情。
- 远程数据库的外键
- 是否也应是本地表的外键。
- 您能否保持对外部数据库的引用完整性
这完全是两回事，尽管两者的快速答案实际上是相同的：
不。
但让我稍微谈谈细节。
1. 对远程数据库使用外键
若要减少对远程数据库的依赖，应仅将这些外键存储在数据库的一个位置。
示例：假设您有一个博客，用户可以在其中发表评论。这些用户将通过Facebook登录。您现在有一个远程数据库（Facebook）和一个存储用户评论的本地数据库。您现在可以遵循以下两种设计之一：
- 将
facebook_id存储为外键的comments表
或
- 一个单独的
users表，用于存储facebook_id以及本地id，以及使用本地 ID 作为外键的comments表。
您不应同时使用两者中的facebook_id。虽然这实际上可行，但您是在不需要的情况下引入对远程数据库的依赖。您将无法添加来自非Facebook用户的评论，因为这会破坏您的设计。
2.与远程数据库的引用完整性
您可能不打算问这个问题，但术语 referential integrity 意味着远程数据库的所有外键实际上都是指现有的远程记录（即用户）。保持这种完整性的唯一方法是远程数据库通知您对远程记录的更改或删除，而通常情况并非如此。
示例：让我们回到上面提到的假设博客。一些Facebook用户发表了评论。后来同一个人决定删除他们的Facebook帐户。Facebook数据库不太可能通知您这种情况，从而使您的数据库中有"死"记录，这些记录不再链接到远程数据库中的有效记录。这会破坏参照完整性。因此，除非您有实际保持这种完整性的好方法，例如接收删除通知等，否则您应该设计您的应用程序，以便在Facebook用户被删除时它不会中断。
建立对外部数据库的引用完整性不是一个好主意。如果需要更快的查找，则应保留自己的 id，然后使用外部 ID，然后使用索引而不是外键约束。
原因是，即使你设法以某种方式建立这种关系，它也变成了一种耦合，使你容易受到另一个系统的变化的影响。
恕我直言：您应该在业务层集成中维护您请求的内容，而不是从数据库级别维护。
实现更改通知系统，理想情况下，在身份验证系统中使用双向服务，您的系统可以订阅该服务，当身份验证系统的 BI 更改时将调用该服务。但是，如果没有，如果您有业务层，另一种方法是为更改提供服务器农场，但这很困难，因为总是会有延迟或性能影响很大。
我相信您最好的方法是使用身份验证系统更改日期戳复制系统中返回的角色等答案，然后使用角色提供程序 api 系统的更改日期来了解您是否可以使用自己的或必须再次获取它，该系统很容易实现， 但应该发生在数据库以外的另一层。
例如，在数据库中应该只是一个 ExternalID 列，它可能与 VerificationDate 耦合，在使用成功时都会更新lY（如果没有，则清除）只是为了保持简单，但不要使用跨数据库关系完整性，就像完全前缀的实例一样，因为它是性能的杀手锏和无法控制的弱点（您的 BI 无法控制其他 BI 想要更新的原因）