Informix Dynamic Server supports a rich set of data types, known as built-in data types. (For information on the built-in types, see the Informix Guide to SQL: Reference.) Informix recommends that you use built-in types wherever possible; however, even with built-in types, consider the following design issues:

• How accessible must the elements of each object be?
• How large is each object?

Object Accessibility

• Use row data types for any object that is a container and whose elements users always want to access.
• Use opaque data types for indivisible objects, or for objects whose representation you want to hide from your users.

If you create Address as an opaque type, each member of the underlying C structure can store a different element of the address. However, this means you must also define accessor routines for each element.

However, if you create Address as a row type, Informix Dynamic Server automatically provides direct access to each of the fields, as follows:

create row type Address
	(street_number real, street_name varchar(40),
	 city varchar(100), country varchar(40),
	 postal_code varchar(20));

select * from employees where address.city = 'Vienna';

When you design data types, ask yourself the following questions:

• Is the data type just a container for a collection of values that users can access directly? If so, use a row data type.
• Is the type naturally indivisible, or do you want to hide its representation from users? If so, use an opaque data type.
• How can you represent your data to make it easy to use in SQL and to make end-user queries simple?

Informix Dynamic Server provides the LVARCHAR data type, which can hold up to 2 KB of text data. Larger objects and binary objects are called smart large objects, and Informix Dynamic Server provides facilities for high-performance access to smart large objects.

A smart large object is an object that is logically stored in a table column of type BLOB (binary large object, for binary data) or CLOB (character large object, for text data), but is physically stored in an sbspace.

An sbspace is a logical storage area that contains one or more chunks that store only BLOB and CLOB data. Sbspaces must be created before you can create any smart large objects; after sbspaces are created, they are managed by Informix Dynamic Server.

Tip: If your DataBlade module makes use of smart large objects, you can test for the existence of a particular sbspace when your DataBlade module is being registered in a database using BladeManager. For information, see Appendix C, "Testing for an Sbspace."

Smart large objects are "smart" because they provide the following features:

• They provide random access to their data, using an operating-system-style interface (seek, read, write, and so on).
• They are recoverable in the event of a system crash (if the sbspace was created with logging enabled), and they obey transaction isolation modes.
• They have no maximum size.
• You can create and store indexes in them.
• You can access and manipulate them using SQL, ESQL/C, or the DataBlade API.

You can also use the Informix LOB Locator DataBlade module to handle large objects. This DataBlade module enables you to store large object data on the client machine. The LOB Locator DataBlade module is included with Informix Dynamic Server with Universal Data Option. You must register the module's routines and data types in each database in which you plan to use the module.

When you design data types, ask yourself the following questions:

• Is the object represented by 2 KB or less of text data? If so, use the built-in LVARCHAR data type.
• Is the object represented by more than 2 KB of text data, or by binary data? If so, use the smart large object facilities provided by Informix Dynamic Server.
• Does it make sense to store the large object on the client computer? If so, use the LOB Locator DataBlade module.

Most of these manuals are accessible through the InfoShelf.