8

DBは削除されたレコードの数を再利用しないため、特にこの列に実際には大きな整数型を選択しない場合は、数が不足する可能性があります。
何が起こり、それが悪い場合にそれを防ぐ方法は？

// SQL Server、MySQL //

4

10 に答える 10

10

Slashdotがコメント機能で行ったように、3 時間以上のダウンタイムが発生します。

于 2008-10-31T14:14:03.653 に答える
5

何が起こるかは、使用しているデータベース エンジンに依存すると思います (MySQL では、INNODB と MyISAM の間に違いさえあるかもしれません)。何が起こっても、それはきれいになることはありません。

列の型をより大きな整数に変更するだけです。

于 2008-10-31T14:10:59.617 に答える
2

MySQL の場合、次のことが文書化されています。

ユーザーが列に負の値を割り当てた場合、または指定された整数型に格納できる最大整数よりも値が大きくなった場合、自動インクリメント メカニズムの動作は定義されません。

于 2008-10-31T14:10:25.907 に答える
2

ほとんどのデータベース システムには、32 ビットを超える数値データ型があります。2^32 を超えるレコードが予想される場合は、適切なキー幅を使用する必要があります。

于 2008-10-31T20:10:07.147 に答える
1

はい、可能です。2 桁の数字のみを許可する場合、99 までの ID しか持てません。制限に達すると、挿入は失敗します。適切なサイズを選択することは常識の問題です。

于 2008-10-31T14:12:51.830 に答える
1

Postgres では、「serial」タイプは、NO CYCLE オプションを指定して SEQUENCE を作成し、フィールドのデフォルトを nextval に設定することと同等です。このようなシーケンスを使い尽くすと、エラーが発生します。

http://www.postgresql.org/docs/8.3/interactive/sql-createsequence.html

于 2008-10-31T14:18:36.733 に答える
1

データベースにもよりますが、私はMS SqlServerを信じています。問題を修正するまで、新しい行を挿入することはできません。最後に遭遇したとき、ID 列を 1 に再シードすることで問題を修正しました。これは明らかに普遍的な修正ではありませんが、私たちの状況では問題ありませんでした。

于 2008-10-31T20:10:17.613 に答える
0

少し前にSQL2000でこれを試しました。Integer.MaxValueの後、次のID値はInteger.MinValueです。その後、期待どおりにカウントアップを続けます。1、2、3などに存在していたレコードがそこに到達するまでになくなっている限り、悪いことは何も起こりません。重複が発生した場合（およびフィールドが主キーである場合）、挿入はキー違反で失敗します。ただし、一意の値に制限されていないID列は試していません。私はそれが複製で満足するだろうと思います。

于 2008-10-31T20:49:18.457 に答える
0

通常、エラーが発生します。あなたが妄想的であるならば、BIGINTを使用してください。

于 2009-10-30T16:18:02.507 に答える
0

Oracle は ID 列の自動インクリメントをサポートしていません。標準的な方法は、シーケンス ジェネレータを使用することです。シーケンスは最大 28 桁の整数を生成するため、それらが不足すると ... かなり大きなテーブルがあると思います。ただし、動作はシーケンス ジェネレーターの構成に依存します。エラーが発生するか、開始値に戻り、次の挿入で PK 制約違反が発生します。

于 2008-10-31T20:31:34.513 に答える