私たちは、ユーザーがまだアクセスできないWebアプリケーションに取り組んでいます。上司は、テーブルに100未満のレコードしかないにもかかわらず、新しく作成されたレコードが10000を超えるIDを取得することに気付きました。彼女は、何らかの理由でWebインターフェースが実際のレコードよりも100倍以上の一時的なレコードを作成（および削除）し、これによりリリース後数か月以内に範囲外になる可能性があると考えました。
彼女はIDインフレーションの原因について正しいとは思わない（これに答えることができる同僚は休暇中なので、私たちは確実に知らない）が、彼女がそうであると仮定しよう。彼女は、bigintカラムを使用するのは嫌いで、IDカラムの自動インクリメントを停止し、最初の「未使用」整数を選択してそれをIDとして使用するサーバー側コードを記述してほしいと言いました。
私はコンピューターサイエンスの大学院生であり、実務経験がほとんどなく、開発者の若手として働いています。彼女は、当社のすべてのデータベースを管理し、それらのほとんどを設計した長年の経験を持っています。私が考える BIGINT IDがの恐れることは何もない、とDBMSの機能を模倣することはアンチパターンの匂いということを、彼女はこの場合には正しくないということ。しかし、私はまだ自分の判断を信用していません。
各ポジションの賛否両論は何ですか？bigintを使用すると、どのような悪いことが起こる可能性がありますか？ホイールの自動インクリメント機能を再発明することの危険性は何ですか？どちらよりも優れた3番目のソリューションはありますか？IDの額面価格の上昇を避けたい理由は何でしょうか？私は実用的な理由についても興味があります-bigint IDは理論的には機能するかもしれませんが、実際には頭痛の種になりますか？
アプリケーションが非常に大量のデータを処理することは想定されていません。今後数年以内に実際の記録が10,000件に達するとは思わない。
違いがある場合は、Microsoft SQLサーバーを使用しています。アプリケーションはC＃で記述され、Linq to SQLを使用します。
更新
ありがとう、私は既存の答えとコメントがおもしろいと思った。しかし、あなたは私の質問を誤解したのではないかと思うので、彼らは私が知りたいことを含んでいます。
高いIDの本当の理由についてはあまり心配していません。自分で見つけられない場合は、別の質問をすることができます。私が興味を持っているのは、この場合の決定プロセスを理解することです。このため、アプリケーションが1日あたり1000レコードを書き込み、そのうちの9999レコードを削除すると想定してください。これは事実ではないと確信していますが、これは上司が要求したときに信じていたものです。したがって、これらの仮想的な状況では、bigintを使用するか、IDを割り当てる独自のコードを作成することの長所と短所は何ですか（すでに削除されたレコードのIDを再利用し、ギャップがないようにする）？
実際の理由については、別のデータベースからデータをインポートするコードを書いたことが、後の移行がある程度できるという概念の証明として、私が強く疑っています。私の同僚は、実際にインポート中に数千のレコードを作成し、後でそれらを削除したと思います。これが実際にそうだったかどうかを確認する必要がありますが、もしそうなら、アクションの必要さえありません。