1

I have to choose a database for implementing a sharing system.

My system will have users and documents. I have to share a document with a few users.


Example: There are 2 users, and there is one document.

So if I have to share that one document with both the users, I could do these possible solutions:

The current method I'm using is with MySQL (I don't want to use this):

Relational Databases (MySQL)
    Users Table = user1, user2
    Docs Table = doc1
    Docs-User Relation Table = doc1, user1
                               doc1, user2

And I would like to use something like this:

NoSQL Document Stores (MongoDB)
    Users Documents:
        {
            _id: user1,
            docs_i_have_access_to: {doc1}
        }
        {
            _id: user2,
            docs_i_have_access_to: {doc1}
        }
    Document's Document:
        {
            _id: doc1
            members_of_this_doc: {user1, user2}
        }

And I don't yet know how I would implement in a key-value store like Redis.

So I just wanted to know, would the MongoDB way I have given above, the best solution? And is there any other way I could implement this? Maybe with another database solution? Should I try to implement it with Redis or not?

Which database and which method should I choose and will be the best to share the data and why?

Note: I want something highly scalable and persistent. :D

Thanks. :D

Community
  • 1
  • 1
Arjun Bajaj
  • 1,932
  • 7
  • 24
  • 41

2 Answers2

1

Considering only this simple example (you just need to keep who owns what) SQL seems to be the most appropriate, as it will give additional options for free, such as reporting who has how many docs, the most popular documents, most active user etc with almost zero cost + the data will be more consistent (no duplication, possibly foreign keys). This is valid unless you have millions of documents of course.

If I chose between document-oriented and relational DB, I'd make a decision based mostly on the structure of the document itself. Whether they're all uniform or may have different fields for different types, do you nested sub-documents or arrays with the ability to search by their contents.

disjunction
  • 646
  • 5
  • 8
  • I would certainly have millions of documents and different data inside different documents. So I think SQL would get slow, and its hard to scale. If I wanted to go with NoSQL, what should I do? Thanks for the answer. :D – Arjun Bajaj Jun 13 '12 at 22:01
  • I have some experience with MongoDB and large amounts of data. Your draft seems to be fine. Just one comment... Having links in both directions is not THAT necessary. You can create an index on members_of_this_doc and you'll be able to make a query searching for all docs, which have a specific user in that array. But it would make sense if you do sharding based on Document._id key - then the link in Users would save time by hitting only relevant shards. – disjunction Jun 13 '12 at 22:58
1

Actually, you need to represent a many-to-many relationship. One user can have several documents. One document can be shared among several users.

See my previous answer to this question: how to have relations many to many in redis

With Redis, representing relationship with the set datatype is a pretty common pattern. You can expect to get better performance than with MongoDB for this kind of data model. And as a bonus, you can easily and efficiently find which users have a given list of documents in common, or which documents are shared by a given set of users.

Community
  • 1
  • 1
Didier Spezia
  • 70,911
  • 12
  • 189
  • 154
  • i read your answer. :D... but isn't there a chance of errors that in the categories set something has been put, and in the users set it has failed? because they are two different operations. i know this is also true for MongoDB, but isn't there a solution that works? – Arjun Bajaj Jun 14 '12 at 08:58
  • With Redis, you can use MULTI/EXEC atomic blocks to group set operations so that you get a all-or-nothing semantic. See http://redis.io/topics/transactions – Didier Spezia Jun 14 '12 at 10:13