FrontBase Documentation

Backtrack:
Welcome!
6. Original Documentation
Updated: 20-Nov-2000
prev — next
Table of Contents

6.18. Object Mapping

The following is a brief description of the recommend mapping of the most common Foundation/Java objects into FrontBase datatypes. See the paper titled "The Datatypes of FrontBase" as concerns a description of the datatypes offered by FrontBase.

NSString
java.lang.String
java.io.Reader
(for CLOB) Suggested datatypes: CHARACTER, VARCHAR, CLOB

Recommended: VARCHAR

Comments: If you are working with large strings and if you most likely are not going to perform searches on the character strings, the CLOB datatype can be a good choice. The main advantage of the CLOB datatype is that the string is sent to the database separately. That is, rather then the database having to parse and copy a huge SQL statement, it can instead efficently transfer the data on a binary channel.

VARCHAR is in general recommended over CHARACTER, as the implementation of VARCHAR is very efficient and allows reuse of identical strings. You can use "open ended" VARCHAR definitions (e.g. VARCHAR(1000000)) without worry for any performance penalty.

The internal representation of character strings is UTF8 with the encoding/decoding taking place on the client side, i.e. handled by the native methods of NSString/java.lang.String.

NSNumber
java.lang.Number Suggested datatypes: BOOLEAN, SMALLINT, INTEGER, FLOAT, REAL, DOUBLE PRECISION

Recommended: INTEGER or DOUBLE PRECISION depending on actual use.

Comments: As NSNumber/Number is a cover for the C/Java number datatypes, the FrontBase type to choose depends on the actual use.

NSDecimalNumber
java.math.BigDecimal Suggested datatypes: NUMERIC, DECIMAL, REAL, FLOAT, DOUBLE PRECISION

Recommended: DOUBLE PRECISION, DECIMAL

Comments: If you are using NSDecimalNumber for accurate calculations, that maps to DOUBLE PRECISION (or DECIMAL if integer) directly. If you wish to reduce storage requirements, you can use FLOAT/NUMERIC instead (the reduction is 8 bytes per value per row).

NSCalendarDate
java.sql.Date
java.sql.Timestamp) Suggested datatypes: DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE

Recommended: TIMESTAMP

Comments: TIMESTAMP WITH TIME ZONE is directly equivalent to the data provided by NSCalendarDate. You might want to consider just TIMESTAMP if you don't have to deal with data in different time zones or if you want data always displayed using the clients time zone.

java.sql.Time Suggested datatypes: TIME, TIME WITH TIME ZONE

Recommended: Either.

Comments: java.sql.Time is a simple wrapper (or just a plain gruesome hack) around java.sql.Date.

NSData
java.io.InputStream Suggested datatypes: BLOB

Recommended: BLOB

Primary key Suggested datatypes: INTEGER, BYTE(12)

Recommended: Either.

Comments: The BYTE(12), which is a cover for BIT(96), datatype should be used if the generation of primary key is done by EOF (client side calculation facility).

Any FrontBase datatype can be used for a primary key and since all numeric datatypes are represented as exact numeric values, it is safe to use e.g. DOUBLE PRECISION or TIMESTAMP as a datatype for a primary key column. However, EOF does not allow certain datatypes (DOUBLE PRECISION, BLOB and CLOB) to be specified for primary key columns, so you will need to consider this if you are using EOF.

FrontBase supports multi-column or compound primary keys, while you should apply some caution if you are using compond keys with EOF.

If you have feedback or questions on this document, please send e-mail to doc-feedback@frontbase.com. Please reference the section number and topic. Thanks!!

NSString java.lang.String java.io.Reader (for CLOB)	Suggested datatypes:	CHARACTER, VARCHAR, CLOB
	Recommended:	VARCHAR
	Comments:	If you are working with large strings and if you most likely are not going to perform searches on the character strings, the CLOB datatype can be a good choice. The main advantage of the CLOB datatype is that the string is sent to the database separately. That is, rather then the database having to parse and copy a huge SQL statement, it can instead efficently transfer the data on a binary channel. VARCHAR is in general recommended over CHARACTER, as the implementation of VARCHAR is very efficient and allows reuse of identical strings. You can use "open ended" VARCHAR definitions (e.g. VARCHAR(1000000)) without worry for any performance penalty. The internal representation of character strings is UTF8 with the encoding/decoding taking place on the client side, i.e. handled by the native methods of NSString/java.lang.String.

NSNumber java.lang.Number	Suggested datatypes:	BOOLEAN, SMALLINT, INTEGER, FLOAT, REAL, DOUBLE PRECISION
	Recommended:	INTEGER or DOUBLE PRECISION depending on actual use.
	Comments:	As NSNumber/Number is a cover for the C/Java number datatypes, the FrontBase type to choose depends on the actual use.

NSDecimalNumber java.math.BigDecimal	Suggested datatypes:	NUMERIC, DECIMAL, REAL, FLOAT, DOUBLE PRECISION
	Recommended:	DOUBLE PRECISION, DECIMAL
	Comments:	If you are using NSDecimalNumber for accurate calculations, that maps to DOUBLE PRECISION (or DECIMAL if integer) directly. If you wish to reduce storage requirements, you can use FLOAT/NUMERIC instead (the reduction is 8 bytes per value per row).

NSCalendarDate java.sql.Date java.sql.Timestamp)	Suggested datatypes:	DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE
	Recommended:	TIMESTAMP
	Comments:	TIMESTAMP WITH TIME ZONE is directly equivalent to the data provided by NSCalendarDate. You might want to consider just TIMESTAMP if you don't have to deal with data in different time zones or if you want data always displayed using the clients time zone.

java.sql.Time	Suggested datatypes:	TIME, TIME WITH TIME ZONE
	Recommended:	Either.
	Comments:	java.sql.Time is a simple wrapper (or just a plain gruesome hack) around java.sql.Date.

NSData java.io.InputStream	Suggested datatypes:	BLOB
	Recommended:	BLOB

Primary key	Suggested datatypes:	INTEGER, BYTE(12)
	Recommended:	Either.
	Comments:	The BYTE(12), which is a cover for BIT(96), datatype should be used if the generation of primary key is done by EOF (client side calculation facility). Any FrontBase datatype can be used for a primary key and since all numeric datatypes are represented as exact numeric values, it is safe to use e.g. DOUBLE PRECISION or TIMESTAMP as a datatype for a primary key column. However, EOF does not allow certain datatypes (DOUBLE PRECISION, BLOB and CLOB) to be specified for primary key columns, so you will need to consider this if you are using EOF. FrontBase supports multi-column or compound primary keys, while you should apply some caution if you are using compond keys with EOF.