たとえば、10 個のエントリを SQL Server テーブルに挿入するかどうか疑問に思いました。それらの1つを削除すると、それに応じてID/インデックスが変更されますか?
例：
1 | Simon Cowell | 56 years
2 | Frank Lampard| 24 years
3 | Harry Bennet | 12 years
#2 を削除すると、Harry Bennet のインデックスは 2 に変わりますか?
ありがとう ：）
編集：私の怒りで申し訳ありません。悪い日でした。はい、私はそれを自分で調査する必要がありました。私は反対票を投じられるに値します。私は何も求めていません。申し訳ありませんと言いたいだけです :|
「id/index」を混同しているように見えるので、リレーショナルデータベースのコンテキストでの主キーとインデックスについて少し話しましょう。
SQL データベースの行に割り当てられた「id」または主キーは、その行の一意の識別子です。1 つ以上の列で構成できます。(複数の列が関係する場合、それは「複合」キーまたは「マルチパート」キーとして知られています。) 主キーは、行をアドレス指定するための一意のハンドルであるだけで、実際には何の役割も果たさないようにする必要があります。特にその情報が変更される可能性がある場合、行によって表されるエンティティに関する情報。例としては、部品が作られている金属の種類を表す接尾辞を持つ部品番号があります。たとえば、その金属がチタンから unobtainium に変更される可能性がある場合、その部品番号は主キーとして不適切な選択になります。金属の種類の接尾辞を主キーの一部にするよりも、金属の種類を格納する別の列を用意する方がよいでしょう。「意味のある」主キーは、従来の非リレーショナル データベースではある程度意味があるかもしれませんが、リレーショナル データベースでは避けるべきです。
主キーの一意性を確保しようとする場合、データベース エンジンはインデックスを利用して、キー値が存在するかどうかを迅速にテストできます。バイナリアルゴリズムを使用して値を見つけることができ、実際のデータを行ごとに「総当たり」でスキャンして値を探す必要がなくなります。 しかし、主キーのハウスキーピングを支援するためにエンジンがバックグラウンドで使用するインデックスは、主キー自体と同じではありません。
主キーとして単純な連続整数がある場合、それらは無限にあるため、割り当てられた行が削除されたときに整数が使用可能になったときに、整数を再利用する必要はありません。そのため、リレーショナル データベース エンジンは自動的にそれを再利用しようとはしません。消す。他のテーブルの他の多くの行がそれらの値を参照している可能性があり、それらを変更可能にすると、混乱または非常に非効率になります。
ハッシュ アルゴリズムは、データベース エンジンがキー値の存在をすばやくテストできるもう 1 つの非常に効率的な方法です。キーが存在する場合にキーが存在するハッシュファイル内の場所を計算し、そこを探します。行は特定の順序で保存されないため、このようなスキームは、郵便番号 10023 のすべての顧客など、共通の特徴を持つレコードを選別するためではなく、大きなテーブル内のレコードを即座に検索するために最適化されています。
いいえ。必要に応じてトリガーまたはロジックを設定できます。ただし、これは自動的には行われません。
いいえ、自動的に変更されません
いいえ、そうではありません。そして、うまくいけば、それがあなたが望んでいる答えです。自動生成された識別子 (IDENTITY 列など) については、可能な限りデータ型を無視し、ID 情報の不透明な "blob" として扱う必要があります。
挿入中に割り当てられ、相互参照の目的で使用できますが、数値であるという事実は、使用または依存するべきものではありません。これは、行の安定した識別子にすぎません。