PL/SQL 変数のデータタイプ 、PL/SQL 固有のデータタイプ

PL/SQL はデータベースに格納できるデータタイプとは種類や精度が異なるものある。
データベースのデータの内部構造と PL/SQL のデータの格納構造の違いはわかりません。( DUMP 関数が使用できないため )
SYS.ANY DATA 型のタイプコードの多くがデータベースのそれと一致しないところからみると、内部では違う形式で格納されていることを連想させる。

参照: データベース上のデータタイプコレクション(配列)型レコード型

PL/SQL 変数のデータタイプ一覧

データタイプPL/SQL におけるデータタイプDB に格納可能なタイプ
CHAR32767 バイト2000 バイト
VARCHAR232767 バイト4000 バイト
(※1) 32767 バイト
  └ RAW32767 バイト2000 バイト
(※1) 32767 バイト
NCHAR32767 バイト2000 バイト
NVARCHAR232767 バイト4000 バイト
(※1) 32767 バイト
LONG*132760 バイト2G - 1 バイト
LONG RAW32760 バイト4G - 1 バイト
NUMBER38 桁 (1E-130 以上 1E126 未満) (※2)
  ├ DECNUMBER のサブタイプ
固定小数点( 38桁 )
-
  ├ DECIMAL
  ├ NUMERIC
  ├ FLOAT浮動小数点
( 約 38桁 )
  ├ DOUBLE PRECISION
  └ REAL浮動小数点
( 約 18桁*2 )
PLS_INTEGER-2^31 〜 2^31-1
マシン算術演算を使用するため変数として2番目に高速
SIMPLE_INTEGER-2^31 〜 2^31-1
ネイティブコンパイル向けに用意された型。NULL やオーバーフローチェックなし。最も高速 Oracle 11g
BINARY_INTEGER-2^31 〜 2^31-1 (約 ± 21 億)-
  ├ NATURAL自然数( 0 以上の整数 )
  ├ NATURALNNATURAL に NOT NULL
  ├ POSITIVE正数( 1 以上の整数 )
  ├ POSITIVENPOSITIVE に NOT NULL
  └ SIGNTYPE{-1, 0, 1}
BINARY_FLOAT
BINARY_DOUBLE
DATE年月日・時分秒
TIMESTAMP年月日・時分秒+小数秒(最大 9桁)
INTERVAL YEAR TO MONTH期間 年、月、日、時、分、秒
INTERVAL DAY TO SECOND
LOB
  ├ CLOB(4G -1)×ブロックサイズ Oracle 10g
4G Oracle 9i
  ├ NCLOB
  ├ BLOB
  └ BFILE4G バイト*3
BOOLEANTRUE、FALSE、(NULL)-

(※1) Oracle 12c において、初期化パラメータ COMPATIBLE = 12.0.0.0以上、MAX_STRING_SIZE = EXTENDED でデータベースを構築またはアップグレードしておく必要がある。従来型と異なる表外格納形式、索引が桁あふれから特殊な方式になることもあってか現行のデフォルト設定ではない。(Oracle12c R2 時点)

(※2) NUMBER 型を精度の指定なしで宣言すると 38 桁保証の精度(プラットフォームによって 39 または 40 桁以内)であるが PL/SQL で NUMBER(*,n) 形式は使用できない。 (Oracle 12c 時点)

ANYDATA 型のタイプコード 識別子

ANYDATA 型 のタイプコードの一部(データベースに格納できるデータのタイプコード

コードデータタイプ
1VARCHAR2
NVARCHAR2
2NUMBER
8LONG
12DATE
21BINARY_FLOAT
22BINARY_DOUBLE
23RAW
24LONG RAW
69ROWID
96CHAR
NCHAR
 
日本オラクル
■ 日本オラクル 株式会社
■ オラクルマスター資格 (オラクルマスターとは
■ Oracle のライセンスがわからない…
Oracle Direct (ネットで聞いても最後はここで要確認)

*1 LONG 系はバインド変数として使用できないため VARCHAR2 としてバインドして処理されると書かれている。長さの上限値も他の文字型と異なる
*2 単純計算は、FLOAT(126) と同じ結果になった。REAL 用にチューニングされた関数を使用しなければ 38桁の精度のままのようである。三角関数などに影響があると思われる。
*3 マニュアルによって異なっている。BFILE は実体を格納しているわけではないので 10g においては(4G -1)×ブロックサイズが正しいかもしれない。