Storage Options for String Domains

There are three categories of database storage for string: small, medium and large, corresponding to the maximum sizes of the CHAR, VARCHAR and CLOB data types in the database. By default, the Cúram generator will place each string domain definition into the smallest possible category based on its size.

For example, in IBM® DB2® the maximum size of a CHAR column is 254 and the maximum size of a VARCHAR column is 32768, so a SVR_STRING of up to 254 will be categorized 'small', a SVR_STRING from 255 to 32768 will be categorized "medium", and larger strings will be categorized as "large" and are stored as a CLOB.

TheStorage Type option allows developers to specify that a string be treated as a small/medium/large regardless of the size of a string. For example, in DB2, this enables developers to use VARCHAR or CLOB instead of CHAR, or CLOB instead of VARCHAR, if necessary.¹

The decision to override the default selection of small/medium/large - i.e. CHAR/VARCHAR/CLOB - is a database tuning exercise which should involve the developer and DBA, and can be quite complex. For example CHAR can be more performant than VARCHAR but uses more space. And while VARCHAR can save space, it can lead to row migration if not tuned correctly. Database tuning is the responsibility of the DBA and is not covered by this document.

This option is applicable to all domain definitions whose eventual type is a SVR_STRING. Specifying this option on a domain definition will affect that domain definition and all domain definitions derived from it - unless it is overridden in one of the derived domain definitions.

For example, consider the following domain definitions:

PHONE_NUMBER is a SVR_STRING<32>.
This domain definition does not have a storage_type option specified so the size 32 means that this domain definition will have a default storage_type of small i.e. it will be stored as CHAR on the database.
BUSINESS_PHONE_NUMBER is a PHONE_NUMBER
This domain definition specifies a storage_type of medium. So instead of CHAR it will be stored as VARCHAR on the database.
ALTERNATE_BUSINESS_PHONE_NUMBER is a BUSINESS_PHONE_NUMBER
This domain definition does not have a storage_type option specified so it inherits the value storage_type specified in BUSINESS_PHONE_NUMBER. Therefore it will be stored as VARCHAR on the database

So while the underlying business meaning of the above three domain definitions is the same - all are phone numbers - they can be stored differently on the database as appropriate.

Note: For database operations on entities in which the parameters are specified by the developer (i.e. nsread, ns, etc.) it is necessary to ensure the domain definitions used in the parameter structs are the same or at least compatible with those in the entity. This is because the type of the domain definition in the parameter struct determines the type of host variable which gets produced in the generated data-access-layer. For example, in DB2, this could mean that a CLOB gets read into a CHAR host variable, or a VARCHAR gets read into a CLOB host variable, etc. The combinations permitted are different depending on the target database type. Caution is advised whenever custom parameters are specified in this way.

Note: For DB2 and IBM DB2 for z/OS® the allocation of strings to CHAR, VARCHAR and CLOB in the database may be impacted by the setting of the Multibyte_Expansion_Factor storage option and related build-time settings. See Multibyte Expansion Factor and the Cúram Server Developer's Guide for more information.

¹ Note that if the developer specifies a Storage Type which is too small for the actual size of the string, the next smallest category will be used. For example, (in DB2), if a developer specifies aStorage Type of small for a SVR_STRING<1000> the generator will still treat this as a medium string since the maximum size of a small string (i.e. CHAR) in DB2 is 254.