Why Not Use LONGs?

In Oracle7, most applications storing large amounts of unstructured data used the LONG or LONG RAW data type.

Oracle8i's support for LOB data types is preferred over support for LONG and LONG RAWs in Oracle7 in the following ways:

• LOB Capacity: With Oracle8i, LOBs can store up to 4GB of data. This doubles the 2GB of data that LONG and LONG RAW data types could store.

• Number of LOB columns per table: An Oracle8i table can have multiple LOB columns. Each LOB column in the same table can be of a different type. in Oracle7 Release 7.3, tables are limited to a single LONG or LONG RAW column.

• Random piece-wise access: LOBs support random access to data, but LONGs support only sequential access. Further, to improve the speed with which a LOB can be brought from the server-side to the client, the LOB can be broken into chunks that can then be brought in a single round trip back to the client.

LOB Type Columns

LOB (BLOB, CLOB, NCLOB, or BFILE) column types store values or references, called 'locators', that specify the location of large objects stored out-of-line or in an external file.

LOB Type Columns Do Not Only Store Locators!

In LOB type columns, the LOB locator is stored in-line in the row, however, depending on user-specified SQL Data Definition Language (DDL), Oracle8i can store small LOBs, less than 4K in-line in the table. Once the LOB grows bigger than approximately 4K Oracle8i moves the LOB out of the table into a different segment and possibly even into a different tablespace. Hence, Oracle8i sometimes stores LOB data, not just LOB locators, in-line in the row.

BLOB, CLOB, and NCLOB data is stored out-of-line inside the database. BFILE data is stored in operating system files outside the database. Oracle8i provides programmatic interfaces and PL/SQL support for access to and operation on LOBs.