Thomas
Thomas

Reputation: 665

CouchDB database design for distributed multi-user audio repository

As part of a rural telecommunication research project, I have implemented a multi-user audio repository running on a linux PC. As I am familiar with RDBMS, I have implemented the backend in MySQL. On this system and using a mostly text-free UI, registered users can create and share recordings with other registered users, who can listen to these recordings when they next logon to the system. This system has been successful and over the past 8 months users have been creating and listening to many recordings.

The other part of our research project has installed a 10-node wireless mesh network in the village. As some users walk upwards of 3km to the current audio repository, we are now investigating how we can create a distributed audio repository running at select mesh node sites. So that users can walk up to a mesh site running the distributed repository and create, share, and listen to recordings. New recordings are then synchronized across all audio repository nodes. As computers and mesh nodes run off of solar panels, both power and connectivity are often intermittent, so we are hesitant to implement a centralized solution. Thus, we think that couchdb and it's filtered replication would offer an ideal solution for our use case.

As I am new to couchdb and come mostly from an Interaction Design background, I am wondering how best to implement the couchdb backend for such a use case. Are per-user databases appropriate, or would this not work since recordings are shared between users? I am a quick learner, but would appreciate some advice on how to design a database where users can register themselves (name, profile picture) and then create private recordings, which can then either be made public or shared with select users? I would also appreciate any help on how to create views that aggregate all recordings that a particular user has created, as well as a view that aggregates all recordings that other users have shared with a particular user. Thank you very much!

Upvotes: 4

Views: 343

Answers (1)

joscas
joscas

Reputation: 7674

I would put everything on a single DB (user recordings and user profiles) instead of creating individual DBs for each user. With that you can use view collation and for example emit a user profile and all owned recordings or all shared recordings with a single view.

To create recordings I would just add recordings documents with a key pair indicating who is the owner. Another key pair could be an array containing the Ids of all profiles with whom the recording has been shared.

For a user interface, to keep it very simple you could use a Couchapp (http://couchapp.org/page/index) but obviously there are many other options to create a user interface.

Upvotes: 2

Related Questions