You could consider computing the hash of your value, and store the mapping from actual value to hash value in another table. When writing your record, store the hash value instead of the actual value. When you need to retrieve the original, use the mapping table to map the hashed value to the actual value. Does that make sense?<br>

<br>Chandru<br><br><div class="gmail_quote">On 27 January 2013 18:00, Szepes Tamás <span dir="ltr"><<a href="mailto:tamas@veriport.eu" target="_blank">tamas@veriport.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

All,<br>
<br>
I have couple of Mnesia tables where the records has some long text fields<br>
with relatively little variation in content (like institute_name which can<br>
be 128 characters long, but in a typical installation there is no more than<br>
20 different values). About 1/3 of my fields are similar and I cannot<br>
determine all possible values in advance to make atoms for them (data from a<br>
new institute can come any time after installation, and the database needs<br>
to be self contained for archiving purposes).<br>
As I need to handle ~10^8 records I’d like to normalize these fields to<br>
spare storage space. However it blows my code if I have to do 3-6 joins in<br>
every lookup operation, not to mention the inserts.<br>
Is there any elegant way of handling this situation?<br>
<br>
Thanks in advance,<br>
Tamas<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br>