Long データ型の機能を備えた LOB には、独自の特別な機能があります。Long の機能を備えているため、Long データ型自体に追加の特別な機能を与えることができます。したがって、もう 1 つのデータ型 LOB を持つ必要はなく、Long 自体は常に使用できます。では、なぜ Long が LOB に置き換えられたのでしょうか?
LOB は LONG の代わりでもありますが、Long は下位互換性のために最新バージョンの Oracle で使用できるようになっています。これは追加のオーバーヘッドですよね？
LOB は、実際には、LONG の CLOB と LONG RAW の BLOB に加えて、BFILE と XMLType の 4 つの異なるデータ型です。Oracle は 1990 年代にこれらの型を導入しました。これは、LONG (および LONG RAW) が Suck! そして非常に扱いにくい。データベースのバージョンが 8.0 以上の場合、LOB の LONG intsad を使用する理由はありません。
では、なぜまだ LONG があるのでしょうか。
LONG および CLOB はプリミティブ データ型です。そのため、オラクルが LONG を修正して CLOB の「追加の特殊機能」を実際に持つことができたのは理論的には真実ですが、データベースを 8.0 (LOB を導入したバージョン) にアップグレードする際に壊滅的な影響を与えたでしょう。
壊滅的と言うのはおそらく大げさですが、実際には、CLOB スタイルの機能を LONG に後付けすることは、データ型を変更することを意味します。したがって、アップグレードには自動データ変換を含める必要がありました。さらに、動作を変更する必要のあるあらゆる種類の低レベル ルーチンが存在する可能性があります。これは、データ破損の大きなベクトルです。新しいデータ型を導入し、個々のサイトに移行を処理させる方がはるかに簡単です (したがって安全です)。
Oracle は 8.0 以降、LONG を非推奨にし、LONG を CLOB に変換するメカニズムを提供しているため、理想的な世界では、誰もが移行し、Oracle はデータベースから LONG データ型を削除できます。しかし、実際には多くのショップが依然として LONG を使用しており、使いすぎると壊れてしまいます。
したがって、オラクルはそれらを保持する必要があります。問題の規模は、Oracle がデータ ディクショナリ (USER_/ALL_/DBA_VIEWS など) で LONG 自体をまだ使用しているという事実から導き出すことができます。