Introduction

---

DBISAM provides different ways of specifying how indexes should be compressed when creating or altering the structure of tables, as well as adding new indexes to a table. Please see the Creating and Altering Tables and Adding and Deleting Indexes from a Table topics for more information. The following information details the different types of index compression and how they should be used.

Types of Compression

---

The four different types of index compression available are:


Compression Recommendations

---

If you are using only non-String fields in an index key and the index is not unique (or primary), then the highest compression level you should specify is duplicate-byte compression. You should not use trailing-byte compression in such a case at all since it will most likely provide very little benefit for most scalar data types (Integer, SmallInt, Word, Boolean, etc.).

If you're using a String field at the end of an index key and the index is not unique (or primary), then you should specify full compression, since this will not only remove duplicate bytes from the beginning of the index key it will also remove any trailing blanks or nulls from the end of the index key. This is especially true with indexes with large index key sizes. However - if the String field at the end of the index key is always filled entirely (such as may be the case with an ID field or something similar) then you should only use duplicate-byte compression for the index. Trailing-byte compression is most effective with large String fields that have a high likelihood of not being filled to capacity very often, such as is the case with an address or company name field.

If you're using only a String field in an index and the index is unique (or primary), you should verify whether the index will be smaller with just the trailing-byte compression specified. The amount of possible compression for the full compression option in this case is limited with unique indexes because there will be a smaller likelihood of duplicate bytes at the beginning of the index keys. It really is a factor of the data values in the table, so you have to experiment a little.

If you're using only a non-String field in an index and the index is unique (or primary), you should verify whether the index will be smaller with no compression specified. The amount of possible compression for the duplicate-byte compression option in this case is limited with unique indexes because there will be a smaller likelihood of duplicate bytes at the beginning of the index keys. This is also a factor of the data values in the table, so again you have to experiment a little.