volunteer wanted to write a few FAQ entries about Mnesia

[Chris Pressey]

On Thu, 20 Feb 2003 16:35:06 -0600
Chris Pressey <cpressey@REDACTED> wrote:

> On Thu, 20 Feb 2003 11:26:13 +0100
> Matthias Lang <matthias@REDACTED> wrote:
> 
> > Hi,
> > 
> > The Mnesia section of the FAQ has been embarassingly barren for far
> > too long. 
> > 
> > I know zilch about mnesia, so I need a volunteer to write that chapter
> > (or help me write it, I'm happy to take care of the formatting and
> > editing). Mail me if you can help.
> > 
> > The alternative is to remove the chapter entirely. Which seems a shame
> > because there are some interesting mnesia-based applications around.
> 
> I can try to make it a bit less barren.  I'll post it to the list in
> case anyone wants to review it and perhaps catch my mistakes (I haven't
> used Mnesia for a while now.)

(As usual I have no idea what I'm talking about... I use Mnesia all the
time, but I've written wrapper functions around mnesia calls, and I don't
tinker with mnesia directly that much, so I rarely think of it that way.)

> What is Mnesia good at?
> 
> Locking and Transactions - if you need to keep a database that will be
> used by multiple processes and/or nodes, using Mnesia means you don't
> have to write your own access controls.
> 
> Distribution - tables can be replicated at many nodes, both for
> efficiency(database lookup is a local activity) and robustness
> (redundancy means if one node goes down, other nodes still have copies
> of the data.)
> 
> Non-fully-normalized data - unlike most database systems, records can
> contain data of arbitrary size and structure.

even funs and pids.

> Monitoring - processes can subscribe to events which are sent when
> various operations on the data take place (update, delete, etc)  The
> RDBMS package allows even more fine-grained control.

It's nice and simple (relatively speaking) as well, and written in Erlang.

> What is Mnesia not so good at?
> 
> It's not as quick as ETS for when you don't need locking, etc.

Mnesia is based on ETS, so it has the same limitations of being primarily
a memory-resident database.

Records are accessed by a single key (which may be unique or duplicate)
and there is no concept of a secondary key.  Typically one can use a tuple
for the primary key instead, perhaps at the small cost of duplicating some
information in the record.

Mnesia itself can't intercept a request to update or delete a record, but
the RDBMS module can do that for it.

Really large tables must be stored in a fragmented manner.

-Chris