Large Object Data Types (Blob, Clob, Dbclob) :: Character Large Objects (Clobs) - A Character String Made Up

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 4

CHAPTER 7

Large Object Data Types (BLOB, CLOB, DBCLOB):


Large object data types store data ranging in size from zero bytes to
two Gigabytes - 1.The three large object data types have the following
definitions:

Character Large Objects (CLOBs) — A character string made up


of single-byte characters with an associated code page. This data type is best
for holding text-oriented information where the amount of information
could grow beyond the limits of a regular VARCHAR data type (upper
limit of 4K bytes). Code page conversion of the information is supported as
well as compatibility with the other character types.

Double-Byte Character Large Objects (DBCLOBs) — A character


string made up of double-byte characters with an associated code page. This
data type is best for holding text-oriented information where double-byte
character sets are used. Again, code page conversion of the information is
supported as well as compatibility with the other character types.

Binary Large Objects (BLOBs) — A binary string made up of bytes


with no associated code p age. This data type may be the most useful
because it can store binary data, making it a perfect source type for use by
User-defined Distinct Types (UDTs). UDTs using BLOBs as the source type
are created to store image, voice, graphical, and other types of business or
application specific data. For more information on UDTs,

Stored Procedures:
Using stored procedures allows a client application to pass control to a
stored procedure on the database server. This allows the stored procedure to
perform intermediate processing on the database server, without transmitting
unnecessary data across the network. Only those records that are actually
required at the client need to be transmitted. This can result in reduced
network traffic and better overall performance.
Applications using stored procedures have the following advantages:
Reduced network traffic
A properly designed application that processes large amounts of
data using stored procedures returns only the data that is needed by the
client. This reduces the amount of data transmitted across the network.
Improved performance of server intensive work
The more SQL statements that are grouped together for execution,
the larger the savings in network traffic. A typical application requires two
trips across the network for each SQL statement, whereas an application
using the stored procedure technique requires two trips across the network
for each group of SQL statements. This reduces the number of trips,
resulting in a savings from the overhead associated with each trip.
Access to features that exist only on the database server, including:
– Commands to list directories on the server (such as LIST
DATABASE DIRECTORY and LIST NODE DIRECTORY) can only run
on the server.
– The stored procedure may have the advantage of increased
memory and disk space if the server computer is so equipped.
– Additional software installed only on the database server could
be accessed by the stored procedure.
Writing Stored Procedures
An application design that includes a stored procedure consists
of separate client and server applications. The server application, called the
stored procedure, is contained in a shared library or class library on the
server. You must compile and access the stored procedure on the server
instance where the database resides. The client application contains a CALL
statement to the stored procedure. The CALL statement can pass parameters
to and return parameters from the stored procedure. You can write the stored
procedure and the client application using different languages. The client
application can be executed on a platform different from the stored
procedure.

The client application performs the following tasks:


1. Declares, allocates, and initializes storage for the optional data
structures and host variables.
2. Connects to a database by executing the CONNECT TO
statement, or by doing an implicit connect. Refer to the SQL Reference for
details.
3. Invokes the stored procedure through the SQL CALL statement.
4. Issues a COMMIT or ROLLBACK to the database.
5. Disconnects from the database

Note: While the stored procedure can issue COMMIT or ROLLBACK


statements, the recommended practice is to have the client application issue
to issue the COMMIT or ROLLBACK. This enables your client application
to evaluate the data returned by the stored procedure and to decide whether
to commit the transaction or roll it back.
.
Note that you can code SQL statements in any of the above steps.
When invoked, the stored procedure performs the following tasks:
1. Accepts the parameters from the client application.
2. Executes on the database server under the same transaction as
the client application.
3. Optionally, issues one or more COMMIT or ROLLBACK
statements.
4. Returns SQLCA information and optional output data to the
client application.
Disk Space Management:
The disk space required for your product depends on the type of
installation you choose and the type of file system you have. On Linux®
and UNIX® operating systems, 2 GB of free space in the /tmp directory is
recommended.

Memory requirements: At a minimum, a DB2 database system requires


256 MB of RAM. For a system running just a DB2 product and the DB2
GUI tools, a minimum of 512 MB of RAM is required. However, 1 GB of
RAM is recommended for improved performance. These requirements do
not include any additional memory requirements for other software that is
running on your system.

You might also like