2 Jul 15:43
Call for Contributions: Mnesia best practices
From: Bob Calco <bobcalco <at> tampabay.rr.com>
Subject: Call for Contributions: Mnesia best practices
Newsgroups: gmane.comp.lang.erlang.general
Date: 2008-07-02 13:46:21 GMT
Subject: Call for Contributions: Mnesia best practices
Newsgroups: gmane.comp.lang.erlang.general
Date: 2008-07-02 13:46:21 GMT
Everyone: I'm looking for thoughts from fellow Erlangers about database design & implementation in Mnesia. With a heavy SQL background I, like many relatively new Erlang folks I'm sure, have a tendency to think in terms of the capabilities of traditional RDBMSs, and to try to normalize every data model with which I come into contact. I'm also used to letting administrators deal with most database operations and issues, whereas with Mnesia the programmer has basically supreme control (both to do some really cool and flexible things, and to do some really dumb things). So the question is generic, not intended to solve a specific problem. I have some ideas and will contribute separately. The question is: What is the best advice you could give a data architect about designing and implementing a database in Mnesia from scratch? Examples of the kinds of issues I'd like to see folks address: * How to create an optimal data model for performance (vs. reporting, comparing the SQL way to the Mnesia way). This question is really about normalization in Mnesia vs. SQL, and tricks like storing whole records in table fields. * How to partition data between subsystems, without losing the illusion they're all one big happy system. * How to handle complex clustering and failover scenarios. * How to handle calculation-intensive databases (for example, stock databases that need to constantly recalculate certain attributes for the purposes of sorting, searching) * How to handle complex domain relationships. For example, let's say you are writing a CRM tool and want to store each "person" in the database. But each person can also be a colleague, or a client, or an incidental character (contact person at some organization). E.e, What do you do when there is inheritance in your domain model? * What are some current pitfalls or "weak spots" of Mnesia that ought to be avoided, however tempting they might be? * How to implement the various callbacks, and what kinds outside of those described in the Mnesia documentation, have been found most useful in practice? That kind of thing. I want to put together something of a master knowledge base on this big subject that the community can use both to promote Erlang and to promote Erlang's "best practices" implementation in the important area of serving data to applications. /Bob
RSS Feed