現在、システムの主キーの長さは 10 桁で、Java 整数の制限をわずかに超えています。これらのキーの数値オーバーフローによって引き起こされる今後のメンテナンスの問題を回避したいのですが、同時に、必要のない無限大の数値を格納するためにシステム パフォーマンスを大幅に犠牲にしたくありません。
主キーのサイズをどのように管理していますか? より大きな Long よりもパフォーマンス上の利点があり、必要に応じてサイズを大きくするために、Java 整数に固執する方がよいでしょうか。シーケンスサイズ?
現在、システムの主キーの長さは 10 桁で、Java 整数の制限をわずかに超えています。これらのキーの数値オーバーフローによって引き起こされる今後のメンテナンスの問題を回避したいのですが、同時に、必要のない無限大の数値を格納するためにシステム パフォーマンスを大幅に犠牲にしたくありません。
主キーのサイズをどのように管理していますか? より大きな Long よりもパフォーマンス上の利点があり、必要に応じてサイズを大きくするために、Java 整数に固執する方がよいでしょうか。シーケンスサイズ?
答えは、Java 整数をデータでオーバーフローする可能性に依存するようです。そして、データが何であるかを知らずにそれを知る方法はありません。
ほとんどすべての状況でこの状況が発生する可能性を単純に排除するため、私は常に長いキー (データベースでは number(18,0)) を使用してきました (極端なデータ ホーディング スタイルのアプリケーションは別として)。すべてのテーブルでキーのデータ型が同じであるということは、親クラスのすべてのモデル オブジェクトでそのフィールドを共有できることを意味し、SQL ゲッターなどの一貫したコードを持つこともできます。
パフォーマンス上の利点はごくわずかなので、長いキーを使用することをお勧めします。将来的にそれに対処しなければならないことは、おそらく大きな問題になるでしょう。
これは、Long 整数の格納と使用のコストと、32 ビット整数のオーバーフローの可能性とのバランスです。
符号なし 32 ビット整数が 40 億を超える値を格納していることを考慮してください。今後 136 年間、このテーブルで毎秒 1 行以上の新しい行を平均すると考える場合は、Long を使用する必要があります。
Java の 32 ビット整数は符号付き整数なので、20 億しかありません。何らかの理由で SEQUENCE がときどきジャンプし続ける場合、PK 間にギャップが生じます。
長くても害はありません (Y2K 問題が発生したのは、一部の COBOL 開発者が日付でいくつかのバイトを保存すると考えたために発生したことを思い出してください ??) :-)
したがって、私は常にロングを使用します。