[erlang-questions] Secondary Mnesia Table index

[Hakan Mattsson]

On Wed, 5 Mar 2008, db wrote:

db> Here is my problem:
db> 
db> I have a unique field in one of the mnesia set
db> table.  Problem is that I can't query on that
db> unique key.

Why?

db> If I create a secondary index, based on another
db> field which is not so unique, this secondary index will
db> bogg down mnesia inserts. Is this also true for
db> dirty_insert?

Yes, dirty updates does also maintain the indecies.

The values of secondary indexed fields must be fairly
unique in order to not slow down updates too much. For
example it is a poor decision to have an index for a
boolean field.

db> mnesia bag table maybe an option.  But in some cases,
db> certain (key, value) pair would become bloated and
db> unhealthy.  The data wouldn't produce good uniform
db> balanced distribution.
db> 
db> I have created first element of mnesia set table to be
db> a tuple, composed of unique_field and
db> not_so_unique_field.
db> 
db> My record looks like this:
db> -record(Tab1, {{unique_field, not_so_unique_field},
db> unique_field, not_so_unique_field})
db> 
db> mnesia set table index is on the first element:
db> {unique_field, not_so_unique_field}

It is a little bit confusing with your choice of record
field names. What are you trying to achieve? Are your
record fields redundant?

The choice of structure for the primary key as well as
the choice of secondary indecies depends a lot of how
you intend to access the record.

db> Would I be able query on not_so_unique_field with an
db> index based on tuple {unique_field, not_so_unique_field} ?

Yes, if you put them in the same record field.

/Håkan