1

資格情報とロールをデータベースに保存しない別のメンバーシップ プロバイダー API がある場合、アプリケーションのユーザー参照との参照整合性をどのように維持すればよいですか?

たとえば、メンバーシップ API とやり取りしますが、メンバー名を渡し、基本的にアクセス プロファイルまたはロールを要求しますが、基盤となるデータベースにはアクセスできません。

次に、返されたロールまたはプロファイルを使用して、アプリケーション内のアクセスを制御できます。このアプローチの問題点は、ユーザーのアクションに関する情報 (変更のログ記録、ワークフローでのタスクの割り当てなど) を保持するときに、プロバイダーからのユーザー ID を保存することですが、その情報はアプリ DB にないため、 DBの整合性を保つためにFKすることはできません。

メンバーシップ プロバイダーは、変更がアプリケーション DB の FK に違反しないことを保証する契約を私たちと結んでいないためです。

しかし、ユーザーごとに自分のアプリ DB 内の情報を集約したり、永続化された UserID への参照を強制したりできるようにする必要があるようです。

名前やプロバイダーからの ID などの定性的な情報を含む別の「薄い」ユーザー テーブルを検討しています...このテーブルは、おそらく最初のログイン時に入力されます。

利点は、アプリケーションのみで一部のユーザー情報に対してユーザー情報を集計できるようになり、アプリ DB 内で参照を強制できることです。欠点は、古い可能性があるユーザー データを複製していることです。

4

2 に答える 2

3

この質問は、実際には 2 つの異なる事柄に関するものです。

  1. リモート データベースへの外部キーは、ローカル テーブルへの外部キーでもある必要があります。
  2. 外部データベースへの参照整合性を維持できますか

これらは 2 つの完全に異なるものですが、両方に対する簡単な答えは実際には同じです。

いいえ。

しかし、少し詳しく説明させてください。

1. リモート データベースへの外部キーの使用

リモート データベースへの依存を減らすには、これらの外部キーをデータベース内の 1 つの場所にのみ格納する必要があります。

例: ユーザーがコメントを投稿できるブログがあるとします。これらのユーザーは Facebook 経由でログインします。これで、リモート データベース (Facebook) と、ユーザーのコメントを保存するローカル データベースができました。次の 2 つのデザインのいずれかに従うことができます。

  • を外部キーとしてcomments格納するテーブルfacebook_id

また

  • usersを格納する別のテーブルfacebook_idと、ローカル ID を外部キーとして使用するテーブルid。comments

両方で facebook_id を使用しないでください。それは実際には機能しますが、必要なくリモート データベースへの依存関係を導入しています。Facebook 以外のユーザーからのコメントを追加することはできません。デザインが壊れてしまうからです。

2.リモート データベースとの参照整合性

これを尋ねるつもりはなかったかもしれませんが、この用語referential integrityは、リモート データベースへのすべての外部キーが実際に既存のリモート レコード (つまりユーザー) を参照することを意味します。その整合性を維持する唯一の方法は、リモート データベースがリモート レコードの変更または削除を通知する場合ですが、通常はそうではありません。

例: 上記の架空のブログに戻りましょう。一部の Facebook ユーザーがコメントを投稿しました。その後、同じ人が自分の Facebook アカウントを削除することにしました。Facebook データベースはそのことを通知しない可能性が高く、リモート データベース内の有効なレコードにリンクされていない「死んだ」レコードがデータベースに残ります。これにより、参照整合性が失われます。そのため、削除通知を受け取るなど、その完全性を実際に維持する優れた方法がない限り、Facebook ユーザーが削除されてもアプリケーションが壊れないように設計する必要があります。

于 2013-10-18T22:59:33.563 に答える
1

外部データベースへの参照整合性を確立することはお勧めできません。独自の ID を保持してから外部 ID を保持し、より高速な検索が必要な場合は、外部キー制約の代わりにインデックスを使用する必要があります。

その理由は、この関係を何とか確立できたとしても、他のシステムの変化に対して脆弱になるカップリングになるからです。

私見：データベースレベルからではなく、ビジネスレイヤー統合で要求しているものを維持する必要があります。

変更通知システムを実装します。理想的には、システムがサブスクライブできる認証システムの双方向サービスを使用して、認証システムの BI が変更されると呼び出されます。変更のためにプロバイダーをファームすることですが、常に遅延が発生したり、パフォーマンスへの影響が大きくなったりするため、これは困難です。

あなたの最善のアプローチは、認証システム変更日付スタンプを使用してシステムに返されるロールなどの観点から回答を複製し、ロールプロバイダー API システムの変更日を使用して、独自のものを使用できるかどうかを確認することだと思います。繰り返しになりますが、そのシステムは実装が非常に簡単ですが、DB とは別のレイヤーで実行する必要があります。

DB では、たとえば、VerificationDate と結合される可能性のある ExternalID 列にする必要があります。単純に保つために、両方とも正常に使用されたときに更新されます (または、そうでない場合はクリアされます)。それはあなたのパフォーマンスにとってキラーであり、制御不能な弱点であるため (BI は、他の BI が更新したい理由を制御しません)。

于 2013-10-25T11:17:28.450 に答える