MBO Attributes

Understand key MBO attribute concepts, before you define them.

	An MBO instance equates to a database row, MBO attributes map to database columns, and in the database, the database row must be less than the page size. See MBO Persistence on the Device.
	Consider row size requirements for localized applications that use multibyte encodings. See MBO Persistence on the Device.
	A smaller page size generally results in better overall database and synchronization performance. See MBO Persistence on the Device.
	If computed maximum row size is larger than specified page size, promotions of VARCHAR to LONG VARCHAR and BINARY to LONGBINARY occur until the row fits into the page.
	Keep MBOs as lean as possible to keep page size small.
	Do not define an MBO with more than 50 attributes.
	For EIS operations where the maximum length information is not provided, the default is STRING(300). Always change this default value to match the expected maximum length using STRING(`n`), where `n` is the actual length of the STRING.

MBO Persistence on the Device

Every MBO instance is stored as a row in a table, and each attribute is represented by a column. Row size depends on the number and type of attributes in the MBO—the larger the MBO, the bigger the row. Since a row must fit within a database page, the page size is influenced by the largest MBO in the package. During code generation, Unwired Server computes the maximum row size of all MBOs to make sure they fit within the specified page size. The computation also takes into consideration the use of any multibyte encoding. In normal usage, the actual row size is often a fraction of the maximum row size. For example, an attribute that holds notes may be more than a thousand characters. Unless the MBO developer pays attention, it is easy for the maximum row size to be unreasonably large.

In the event that the maximum row size computed during code generation is larger than the specified page size, VARCHAR columns are promoted to LONG VARCHAR to move storage out of the row until the row fits in the page. This results in an indirection to access the data, and may impact query performance. To avoid indirect access:

Eliminate attributes not required by the application.
Reduce the maximum size. For example, the EIS may have a notes field with a 1000 character limit. Use a smaller size for the mobile application if possible.
Consider splitting the MBO if it contains many attributes.
Analyze data to determine the normal row size. Use a page size large enough to hold the row. Code the mobile application to configure the mobile database to run with this page size. During code generation, a much larger page size is used to avoid promotion, but the application runs using a small page size. A drawback to this approach is a possible synchronization failure when the actual data exceeds the page size specified during runtime. The developer must determine the minimal page size with the lowest probability that the actual data exceeds it.

Why Page Size Matters

Sybase testing indicates that a page size of 1 – 4KB provides the best overall performance. Start testing with these sizes, unless the MBO model requires a larger page size. The main issue with large page size is related to slow write performance of Flash-based file system/object storage used by the device. The impact is most evident during synchronization, when the database applies the download transactionally.