Mnesia data partitioning question

[Chandrashekhar Mullaparthi]

Since you say that space is not an issue - you could generate a unique
integer index for every order_id+shipment_id combination and make the
generated index the primary key and the order_id and shipment_id as
secondary indices. Space will still be wasted - but a little less.

cheers,
Chandru

-----Original Message-----
From: Chris Pressey [mailto:cpressey@REDACTED]
Sent: 16 April 2002 22:43
To: erlang-questions@REDACTED
Subject: Mnesia data partitioning question


Although I don't really expect a concrete answer to this one, I thought it
might be interesting to share opinions on the subject...

Mnesia lacks the concept of a 'secondary key' - that is, using more than one
field to uniquely identify a record.  So, is it, generally speaking, wiser
to model a many-to-many relationship in Mnesia as:

- a 'set' table with a compound key, or
- a 'bag' table with an index on a second field?

Perhaps I should give some background.  I am currently using Erlang outside
of telecom - in a retail setting - for an order-tracking application.  I
chose Erlang partly because the problem is inherently distributed and soft
real-time - users in different physical locations want immediate updates on
the status of orders.  Erlang makes this easy - the shipping department
manages a database, and all the other nodes simply subscribe to Mnesia
events, and update their displays accordingly.

Orders go out in shipments.  If orders are small, more than one order may be
placed in the same shipment.  If an order is large, it may be split across
more than one shipment.  So there is a many-many relationship between
shipments and orders, and the key in the main table is order_id+shipment_id.
I've currently implemented this as a compound key, i.e. a 'set' table where
the key is a tuple {order_id, shipment_id}.  Unfortunately, I need indexes
on the order_id and shipment_id fields individually, for other purposes, so
they are repeated in the record - wasting space.

<snip>



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.