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

有帮助吗?

解决方案

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.

其他提示

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.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top