1

私はプロジェクトに取り組んでおり、Web アプリと SQL の両方が初めてなので、ご容赦ください。API を作成しています。別のテーブルの顧客 ID への外部キーを持つ特定のテーブルの特定の行にのみユーザーがアクセスできるようにしたいのですが、別のテーブルのユーザー ID によって検証する必要があります。(1 人の顧客が複数のユーザーを持ち、複数のアセットを所有しています。現時点では、顧客のすべてのユーザーが任意のアセットにアクセスできますが、アセットまたはユーザーを共有する顧客はいません。)

SELECT * FROM [Asset] WHERE Id=@AssetId AND CustomerId=(SELECT CustomerId FROM [User] WHERE UserId=@UserId);

これはすばらしいことですが、Asset テーブルと User テーブルに多くのエントリがあるため、このクエリには膨大な時間がかかる可能性があります。アセット データを必要とする API へのすべてのリクエストがこのチェックを行う必要があるため、これは悪いことです。インデックスを設定できました。実際、UserId は認証プロバイダーからの一意の識別子であるため、User のセカンダリ キーですが、アセットに CustomerId のインデックスを追加する必要があるかどうかはわかりません。Asset テーブルは、他のテーブル (監査用のメッセージング レコード テーブルがある) に比べて比較的ゆっくりと成長するはずですが、それが正しい答えなのか、それともより最適化された簡単な答えがあるのか​​ はわかりません。それとも、この種のクエリは大規模で高速なので、心配する必要はありませんか?

4

1 に答える 1

1

あなたの特定のケースでは、User テーブルと Asset テーブルの間にジャンクションテーブルを構築するのに最適なコンテキストのように見えます。両方のフィールドが一緒になって主キーになります。個別に、AssetId と UserId は外部キーになります。

ジャンクション テーブルの名前が AssetUser であるとします。

外部キー:

CONSTRAINT [FK_AssetUser_User] FOREIGN KEY ([UserId]) REFERENCES [User]([UserId])

CONSTRAINT [FK_AssetUser_Asset] FOREIGN KEY ([AssetId]) REFERENCES [Asset]([AssetId])

主キー:

CONSTRAINT [PK_AssetUser] PRIMARY KEY([AssetId], [UserId]));

大量のデータが必要な場合やアプリケーションのパフォーマンスが重要でない限り、スケールについてあまり心配する必要はありません。その場合、hadoopを使用するか、NoSQL データベースに移行するかを選択できます。

于 2015-07-20T23:26:59.110 に答える