Skip to main content
Version: Current

Data Structures - Indices

Indices are key components of any database. In the Genesis platform, every table must have at least one index: the primary key. This is vital for controlling how data is read by an application.

  • Unique indices are required for get operations.
  • An index is required for getRange operations. This can be either unique or non-unique.
  • In getBulk operations, the index determines the order in which records are returned.

Operations and indices

An index can be unique or non-unique. In addition, an index with multiple fields can be searched across all the fields or partially searched across a subset of fields:

Can be used in a gettruefalsefalse
Can be used in a getBulktruetruetrue
Can be used in a getRange(index)falsetruetrue
Can be used in a getRange(from, to)truetruetrue

Unique index

Unique indices, including primary keys, can not have two records with the same value. An example would be an index on the TRADE_ID field in the TRADE table. This guarantees that every TRADE_ID in the database is unique, and allows the TRADE table to be queried by TRADE_ID.

Non-unique index

Non-unique indices are useful when data needs to be queried, but where uniqueness is not important or not an option. For example, if the application has Trades with one or more corresponding Orders, the TRADE table could have a non-unique index on the ORDER_ID field. This index would allow the TRADE table to be queried by a specific ORDER_ID.

Partial searches

On indices with multiple fields, look-ups can also be done on a subset of fields - but the look-up must start at the first field and cannot skip a field. For example, if a table has an index defined with 3 fields, you can search on:

  • the first field
  • the first and second fields
  • all three fields

You cannot look up on field 1 and field 3 only. The partial search behaves like a non-unique index, even if the index itself is unique.

Fields must always be provided in order.