Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm in the planning stages of a new webapp, and I am leaning strongly toward a multitenancy model. The app has a file storage function, where the user can upload (and operate on) files.

I would like the ability of the user to share these files, however. How is this typically accomplished in a multi-tenant model?

The example would be something like google docs. Each user has their own files; they can edit and tag and build collections with these files. Then, they can share a doc or a collection with someone else for collaboration.

If every user has their own Database and tables, what strategy would one use to allow this kind of sharing while minimizing duplication of files and associated metadata?

share|improve this question
2  
Have a common database, tables and repository with appropriate permissions for the file sharing function. If you don't need "Chinese walls" between tenants, it is better to use a single database for everything. –  Robert Harvey Jun 12 '12 at 16:30

2 Answers 2

You want a single database, one single file store.

Multiple databases are only the way to go if you have an app which is not designed for multitenancy and it is not feasible to adapt it to use a single database.

If you have a logical entity scattered across more than one database, the database is not going to be able to enforce integrity and you will have to deal with problems caused by that- and that's just one of the many problems you will have.

Having a single database for a multi-tenant app is not a problem when you design the app from scratch- it definitely requires more work to really isolate different tennants [i.e. all your queries will need a customer=xxx condition, and you cannot forget about that], but it's certainly something less troublesome than having multiple databases.

Once you have a single database, it's just a question of schema design and n-m relationships (i.e. 1 document can belong to n users, 1 user can have m documents).

If you have a normalized schema, data duplication won't be there, by definition :)

share|improve this answer

You'll want to avoid duplicating the files and dealing with locking mechanisms and conflict resolutions as a result. You can follow a model whereby editing rights are shared on a file as opposed to duplicating the file to be edited by another party.

Sharing editing rights can be enhanced with collaboration by allowing multiple users to edit the same document at the same time (if your app has such a feature) and helps users avoid overwriting each others changes. You can avoid the overwriting issue by keeping a history of saves of course but in my experience, a user may not notice that an update was just made to a document they were working on or uploaded unless the UI makes that fact stand out.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.