私はOracle Database 12c Enterprise Editionリリース12.1.0.2.0-64ビット製品を使用していますが、INTEGER
またはNUMBER
を使用する整数フィールドに---を保持することにしました LONG
Javaから。
参考のために:
_Long.BYTES = 8
Long.SIZE = 64
Long.MAX_VALUE = 9223372036854775807 / 2^63-1
_
比較的古いブログ投稿 から Stack Overflowの回答 に誘導されました。これは、INTEGER
を使用するべきではないことを示唆しています。 NUMBER
の使用と比較した問題。 [〜#〜] id [〜#〜]列のみでも同様です。
INTEGERは常にNUMBERより遅くなります。整数は制約が追加された数値なので。制約を適用するには、追加のCPUサイクルが必要です。違いを見たことはありませんが、INTEGER列に数百万のレコードをロードすると違いが生じる可能性があります。入力が整数であることを確認する必要がある場合は、INTEGERが最適です。それ以外の場合は、NUMBERデータ型をそのまま使用できます。
この記事では、 "INTEGERは、すでに知っているNUMBER(38,0)"と同等であるとも述べています。提起されたパフォーマンスの懸念の可能性と同等であるかどうかを判断できませんでした。
INTEGER
、INT
およびSMALLINT
はすべてNUMBER(p,0)
にマップされます
ですから、いつものようにNUMBER(38,0)
を使用することを計画しています。データをインポートする多くのレガシーデータベースとテーブルから、実際にこのID
情報をVARCHAR(50)
に保存し、 prefix/suffix文字を追加してstateを示すため、データは非常に恐ろしいゴミです。 _z343234
_のように、disabledを意味します。したがって、私は新しいシステムでこのデータをクリーンアップし、以前の開発者/ビジネスアナリストが行った改ざんを許可しないようにしています。 私は、破損したフラグやその他のデータを保存することには関心がなく、数値部分だけを保存しています
私は非常に多くの異なるデータベースエンジンを使用しているため、最新のイディオムが何であるかについていけません。
その投稿の背後にある論理は馬鹿げているので、皮肉な答えに値します。
Oracleは「それは整数ですか?」ディスクへのI/O呼び出しが主キー制約を検証するために必要なデータを返すのを待っている間に確認します。
このパフォーマンス拡張機能は、Oracleバージョン2に実装されたと思います。
実際には、このようなチェックを実行するために必要なクロックサイクルの数はごくわずかであり、コンピューターの通常の操作のノイズ内に簡単に隠れてしまいます。 VAX/VMSでもパフォーマンスの違いを測定できなかったと思われます。 (「10年」よりはるかに古い)
ご覧のとおり、INTEGER
はNUMBER(38,0)
です。測定可能なパフォーマンスの違いがあってはなりません。
_PLS_INTEGER
_とNUMBER
について話していると、違いが出てきます。これが真であることを証明するベンチマークのほとんどは、計算集約型です。この値で微分方程式を実行していないため、「パフォーマンスの向上」はあなたのケースには当てはまりません。
INTEGER
またはNUMBER(38,0)
を使用することをお勧めします
番号とフラグは2つの異なる列にある必要があります。 _virtual column
_(3番目の列)を使用して元の文字列を自由に取得してください。 _virtual column
_ロジックが人間が実際に入力した内容と一致する場合に人間が検索できるように、元の文字列値を「コメント/メモ」のようなフィールドに記録することをお勧めします。