web-dev-qa-db-ja.com

OracleにおけるINTEGERとNUMBERの現在の状態

私は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）"と同等であるとも述べています。提起されたパフォーマンスの懸念の可能性と同等であるかどうかを判断できませんでした。

  1. すべての値が整数にすぎないことを確認したいのですが。
  2. この列は何百ものテーブルへの外部キーになるため、定期的に数百万の行を処理し、この列で結合します。

Oracleドキュメント は

INTEGER、INTおよびSMALLINTはすべてNUMBER(p,0)にマップされます

ですから、いつものようにNUMBER(38,0)を使用することを計画しています。データをインポートする多くのレガシーデータベースとテーブルから、実際にこのID情報をVARCHAR(50)に保存し、 prefix/suffix文字を追加してstateを示すため、データは非常に恐ろしいゴミです。 _z343234_のように、disabledを意味します。したがって、私は新しいシステムでこのデータをクリーンアップし、以前の開発者/ビジネスアナリストが行った改ざんを許可しないようにしています。 私は、破損したフラグやその他のデータを保存することには関心がなく、数値部分だけを保存しています

私は非常に多くの異なるデータベースエンジンを使用しているため、最新のイディオムが何であるかについていけません。

これらのパフォーマンスの問題は、実際には約10年後に懸念される問題ですか？

oracleoracle-12c
5
user68575

ブログ

その投稿の背後にある論理は馬鹿げているので、皮肉な答えに値します。

Oracleは「それは整数ですか？」ディスクへのI/O呼び出しが主キー制約を検証するために必要なデータを返すのを待っている間に確認します。

このパフォーマンス拡張機能は、Oracleバージョン2に実装されたと思います。

実際には、このようなチェックを実行するために必要なクロックサイクルの数はごくわずかであり、コンピューターの通常の操作のノイズ内に簡単に隠れてしまいます。 VAX/VMSでもパフォーマンスの違いを測定できなかったと思われます。 （「10年」よりはるかに古い）

INTEGER vs NUMBER vs PLS_INTEGER

ご覧のとおり、INTEGERはNUMBER(38,0)です。測定可能なパフォーマンスの違いがあってはなりません。

_PLS_INTEGER_とNUMBERについて話していると、違いが出てきます。これが真であることを証明するベンチマークのほとんどは、計算集約型です。この値で微分方程式を実行していないため、「パフォーマンスの向上」はあなたのケースには当てはまりません。

INTEGERまたはNUMBER(38,0)を使用することをお勧めします

データモデルの提案

番号とフラグは2つの異なる列にある必要があります。 _virtual column_（3番目の列）を使用して元の文字列を自由に取得してください。 _virtual column_ロジックが人間が実際に入力した内容と一致する場合に人間が検索できるように、元の文字列値を「コメント/メモ」のようなフィールドに記録することをお勧めします。

4
Michael Kutz