FrontBase logo

FrontBase Documentation

FrontBase logo

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!!

©2000 FrontBase, Inc. All rights reserved.