[erlang-questions] Mnesia questions

[Igor Ribeiro Sucupira]

To model your data, I think it's a good idea to first decide what are
the operations you're going to need.

Also, I can't understand whether each item is specific of a person or
the same item can belong to more than one person.

Supposing that each item belongs to only one person and that you need
to be able to:
- Retrieve all the items of a person.
- Retrieve a specific item of a person.
- Insert an item for a person.

I think you would be fine with a table that has:
- {PersonKey, ItemKey} as the primary key.
- Another field for PersonKey.
- An index on the field above.

This way, the items of the same user may be distributed among several
fragments, what is probably what you want.

Using a bag with the person as the primary key, all the items for the
same user will be on the same fragment. Also, accessing a specific
item will be slower.

Good luck.
Igor.

On Mon, May 17, 2010 at 8:32 PM, Chris Hicks
<silent_vendetta@REDACTED> wrote:
>
> First off thank you to everyone who responded publicly and privately. I do have a couple more specific ones about Mnesia and fragmented tables (yes, more of THOSE questions).
> 1) Well my first question is actually about tables in general. When one inserts/deletes a record/row from a table, is the whole table locked(didn't see this anywhere but could have missed it)?
> 2) I understand the general concept behind fragmented tables, and the answer to the above question may render part of this moot, but what are the performance pros/cons for using fragmented tables? I don't mean disk space but read/writes which occur mostly in transactions. Is each one any slower? Is there any advantage in parallelization?
> 2a)If a whole table is locked for an update does that just mean (hopefully) that the specific fragment of the larger table would only be locked, meaning a 50 fragment table could have 50 different locks/writes going? Of course if a whole table is not locked for an update that doesn't matter.
> One of the data requirements for my project is that one "person" record will be associated with possibly as many as 1000 "item" records. Lets take a possible person population of 10,000, meaning there could be as many as 10M item records. I want to keep each record small as I will be accessing different parts of a whole "object" at different times and will only need one or two small pieces of data at a time. One of the ways, and some of this is going to rely on the answers above, I was thinking of doing this was setting up a bag type table and associating all of those items (because they will be different) with the same key, the id of the person record. The one thing I'm wondering about, however, is some of these items might be in table fragment 1 and others in fragments 13, 27 and 42 (as far as I understand it) and I was wondering how much of a problem this would create as far as performance.
> Having each item with a different primary key, with each key held in a field in the person record, would mean I have a ton of queries if I want to get detailed info about each item and that doesn't work for me. Is there another approach that would be better that I am not thinking of?