ID主キーでIdentityを使用しています。そして、いくつかのデータを挿入します。例えば。
データ 1 -> 追加 エラーなしで成功。 ID 1
データ 2 -> 追加 エラーなしで成功。 ID 2
データ 3 -> 追加 エラーで失敗。
データ 4 -> 追加 エラーで失敗。
データ 5 -> 追加 エラーなしで成功。 ID 5
ID が 2 から 5 にジャンプしたことがわかります。
どうして ？？どうすればこれを解決できますか??
1115 次
4 に答える
3
なぜそれが問題になるのでしょうか？
通常、主キー列でIDを使用します。次に、この主キーは代理キーです。つまり、ビジネス価値/ビジネス上の意味はまったくありません。これは単なる「管理上の」事実であり、データベースがレコードを一意に識別できるようにするために必要です。したがって、この値が何であるかは問題ではありません。また、ギャップがあることも問題ではありません。なぜそれらを連続させたいのですか。
そして、それらが連続していると仮定します-挿入が失敗したときにギャップが表示されない-行を削除して後で挿入する場合はどうしますか？ギャップも埋めていただけませんか？
于 2010-01-07T22:23:42.340 に答える
0
@Frederikはそのほとんどに答えました-主キーとビジネスキーを混同していることを付け加えておきます。請求書（またはその他）は、請求書番号（テーブルにUNIQUE列が必要なビジネスキー）で識別される必要があります。主キーは、テーブル内の行を識別するためにここにあり、データベース（..を結合するため）およびDBAのみが使用する必要があります。
主キーをビジネスユーザーに公開すると問題が発生し、データベースは遅かれ早かれ参照整合性を失います。常にそうですが、人々は創造的です。
于 2010-01-07T23:39:34.200 に答える
0
挿入が失敗した場合は、次の挿入でset identity_insert mytable on を使用し、max(myfield)+1 を使用して次の ID を手動で計算できます。ただし、同時実行の問題が発生する可能性があります。
しかし、これは塊です。隙間があっても問題ありません。
于 2010-01-07T22:29:49.333 に答える
0
これは設計によるものであり、SQL サーバーは最初にカウンターをインクリメントし、行の作成を試みます。失敗した場合、トランザクション (常に暗黙的なトランザクションがあります) はロールバックされますが、自動インクリメント値は再利用されません。これは仕様によるものであり、回避できることに非常に驚かされます (最終的には、何らかのコマンドを呼び出して、値を現在の最大値にリセットできます)。いつでもトリガーを使用してこの値を生成できますが、これにはパフォーマンスへの影響があります。通常、auto_increment の値は単なる整数であることを気にする必要はありません。
于 2010-01-07T18:47:52.670 に答える