sql - 主キーまたは一意キーでレコードを更新します

Question

ストアドプロシージャの設計に関するベストプラクティスについて、テーブル内のレコードを更新するストアドプロシージャは、更新するレコードを識別するために主キーを使用する必要がありますか、それとも一意キーを使用する必要がありますか？

一意キーは送信する追加のパラメーターがたくさんあるようで、主キーがわからない状況は考えられません。

Answer 1

「一意のキー」とは、「ビジネスキー」を意味すると思います。外部ソースから大まかに同期されているデータベースがある場合は、ストアドプロシージャのパラメータとしてビジネスキーを使用すると便利です。

製品の注文、サービスのアクティブ化、プロセスの開始などのために、別の会社からフラットファイルを受け取ったとします。彼らはおそらく主キーを知らず、名前で要求される可能性があります:(会社X、サービスY、アクティブ化）一意の会社名、一意のサービス名、一意の状態に基づいてストアドプロシージャを呼び出します。確かに、リモートシステムはIDを使用する必要があると言うかもしれませんが、それは時々あなたのコントロールの外にあります。

別の例：アプリケーションレベルで実行されるレプリケーション。シーケンスが2つのデータベース間で同期していない可能性があるため、リモートレコードを参照する方がビジネスキーの方が安全です。

Answer 2

この質問には2つの異なる側面があります。

• 目標：達成したいことは、特定の行を更新することです。このポイントに到達できるようにする手段はどれも良いことです。言い換えると、一意性キー、主キー、または単一性制約の下にリストされていない列の他の組み合わせが問題ない場合は、それを使用できます。
• パフォーマンス：他のクエリと同じように、あなたは本当に速くそしてまっすぐにポイントに行きたいです。どういう意味ですか？これは、where句で最も効率的なフィルターを選択する必要があることを意味します。これは次の方法で測定できます。

1 /使用しているインデックスのサイズ：最小のものを選択します（たとえば、列のサイズ）

2 /使用しているインデックスの列の非null属性:(エンジンがnull許容列で一意のインデックスを許可している場合）できれば、非null可能列に配置されるインデックスを選択します。

3 /インデックスのテーブルスペース：パフォーマンスを向上させる、インデックス用の特別なストレージがあるかどうかを確認することもできます（マウントされたインデックス...）

4 /列タイプ：通常、小さい数字はテキストよりも解析が高速です（ソースがないことをお詫びします。注意してください）

今はこれ以上考えられませんが、他の人がリストを完成させると確信しています。

乾杯。