既存のデータがある場合に SQL で ID 列を再シードする方法は? すべてのデータが更新された ID (関連付けの外部キーにも反映される) を取得するように、この操作を実行する簡単な方法はありますか?
編集: ID 列の制限に達した場合はどうなりますか? その場合、あなたはどうしますか?それが私がこの質問をした理由です。この種の問題をどのように解決できるかを理解したいだけです。
既存のデータがある場合に SQL で ID 列を再シードする方法は? すべてのデータが更新された ID (関連付けの外部キーにも反映される) を取得するように、この操作を実行する簡単な方法はありますか?
編集: ID 列の制限に達した場合はどうなりますか? その場合、あなたはどうしますか?それが私がこの質問をした理由です。この種の問題をどのように解決できるかを理解したいだけです。
これを自動的に行う方法はありません。これを行うために独自のスクリプト セットを作成することもできますが、既存の ID 範囲を「圧縮」する商用 (MS またはその他の) ソリューションについては知りません。しかし、アーロンが言ったように、そもそもなぜこれをしたいのでしょうか?
SQL Server の ID 値にギャップがないことや、単調に増加することさえ保証されていません。詳細については、http://sqlity.net/en/792/the-gap-in-the-identity-value-sequence/をご覧ください。
値を単調に増加または継続させる必要がある場合は、独自の「値プロバイダー サービス」を開発する必要がある場合があります。
これが可能なHACKソリューションです。
元の IDENTITY 定義で「0」から始めましたか。
-MAX から -1 まで自由に使用できます。
DBCC CHECKIDENT ('MyTableName', RESEED, -2147483648);
ただし、「if myKey>0」などの爆発をチェックするアプリケーション コード (例: DotNet) を使用することもできます。
これを行った場合、テーブルが -1 に達すると失敗する追加の CHECK 制約を配置します。
繰り返しますが、私は本当にそれをお勧めしません。しかし、可能性としてそれを提供してください。
IDENTITY を (「昔」から) 数回使用したことがありますが、実際には -MAX 値でシードを開始します。
一例です。その下に FK がないログ テーブル。毎週フラッシュされる監査データをスローするための単なるテーブルなので、実際には問題ではありませんでした。IDENTITY は単純に何らかの順序を与えただけです。