問題タブ [primary-key-design]

私たちは新しい REST API を構築しており、主キーとべき等性キーに関していくつかの決定を下す必要があります。私たちの API には多くのユーザーがいて、ユーザーは自分に属するオブジェクトの検索のみが許可されています。userIdリクエストは認証されるため、特定のリクエストに関連付けられていることがわかります。

懸念される特性:

• userIdユーザーの ID。
• idempotenyKeyAPI へのべき等リクエストで使用されるべき等キー。ユーザーごとに一意です。

議論の基礎となるCarsエンドポイントを含む架空のテーブルがあるとします。GET .../cars/{id}

オプション

オプション 1 - userId と idempotencyKey の複合を主キーとして使用する

アイテム検索: GET .../cars/{idempotencyKey}

考え:

• ルックアップで使用される ID は推測可能です。
• オブジェクトは認証されるため、これが差し迫ったセキュリティ上の懸念を引き起こすようには見えませんが、ユーザーのユーザーが何かを検索できるようにするエンドポイントが API に存在する場合は、検索が推測可能であると想定する必要があります。

オプション 2 - userId + idempotencyKey のハッシュを主キーとして使用する

挿入するときは、 を計算しid = hash(userId + idempotencyKey)ます。

アイテム検索: GET .../cars/{id}

考え:

• 主キーは推測できません。
• これにより、 に対する操作でのセキュリティ リスクの可能性がさらに防止されますids。
• 複合主キーではなくなりました。
• オプション 3 とは異なり、(userId, idempotencyKey) に対する一意の制約は必要ありません。

オプション 3 - uuid 主キーの生成

挿入するときは、 を設定しid = UUID.randomUUID()ます。

アイテム検索: GET .../cars/{id}

考え:

• id は完全に推測不可能であり、ビジネス データに関連付けられていません。
• 追加のインデックスが必要です。

オプション 4 - ユーザーに公開されない、自動インクリメントされた主キー

ルックアップを行うにはいくつかの方法があります。ルックアップは、idempotencyKey のみに基づくことができます。つまり、次のようになります。 GET .../cars/{idempotencyKey}

または、参照 ID uuid を自動生成し、インデックスを作成してルックアップに使用することもできます。

考え:

• 主キーがユーザーに公開されることはありませんが、これはかなり一般的な方法です。
• ビジネス ロジックが変更された場合の柔軟性が向上します (ただし、userId や idempotencyKey などの基本的な概念については、これらがどのように変更されるかわかりません)。
• 主キーは INT であるため、より小さくなります。これにより、インデックスが小さくなり、おそらくパフォーマンスが向上します。
• ここでも追加のインデックスが必要です。

どのようなアプローチを取るべきかについてのアドバイスを探しています。パフォーマンスとスケールに関する考慮事項は非常に重要です。

ありがとう！

テーブルに主キーがありません。userId と cartId を一緒に使用 したいです。

2列をプライマリとして定義する必要がありますか? どうやって？

600 万レコードのテーブルに主キーを作成したいのですが、これを実行すると:

テーブルがロックされており、alter table の実行が終了しません...

以下に示すように、2つのテーブルがあります。

トランザクション テーブルは、バイヤーとサプライヤー間の販売イベントを表すテーブルです。表の ... は、TransactionDate、ストア情報などの他の列を表します。

連絡先テーブルは、名前や自宅の住所など、バイヤーとサプライヤーの情報を表すテーブルです。

現在、2 つのテーブルは、BuyerID = ContactID および SellerID = ContactID という 1 対 1 の関係を共有しています。

このテーブルに Python スクリプトを入力しているので、答えは Python、SQL、またはその両方である可能性があります。

現在の状態

取引表

連絡表

私がしたいのは、連絡先テーブルの繰り返し行を削除し、テーブルの関係を 1 対多にすることです。さらに、たとえば Janet Myers が姓を変更した場合、他のすべての列が同じままであっても、Contact テーブルに新たに追加されます。つまり、ContactID 列を無視すると、ContactTable に 2 つの同一の行があってはなりません。

将来の状態

取引表

連絡表

これを解決するために最初に考えたのは、他のすべての列のハッシュから ContactID を作成することです。

次にMERGE、ContactID ハッシュがまだテーブルに存在しない場合は、ステートメントを使用して連絡先を追加します。これはうまくいくと思いますが、財務データとのハッシュ衝突の危険を冒すことを考え直しています。

ハッシュ以外に、私の他の考えはMERGEステートメントですが、ON句に約 15 の列があるため、パフォーマンスが非常に低いと思いました。