Reputation: 244
I'm in the early stages of making a blogging site where users can have multiple blogs. I've decided to use document based storage for the blog entries (either MongoDB or CouchDB).
However, I will need to manage my users—mostly for authentication. Can this be done in a document-oriented database? How would I set that up? One document listing all the users seems like a bad idea. Or, Should I fall back to a relational database for this (most likely MySQL)?
Upvotes: 3
Views: 272
Reputation: 21836
It's perfectly possible, and in my opinion, a good idea. Like Remon says, the schema-less design of a document database is a good idea for flexibility.
To answer your question about how to model it, I would suggest (in mongodb) a collection of documents called users, with one document in the collection for each user. A unique index on the collection by user name would be a good idea.
Upvotes: 0
Reputation: 18595
It's perfectly possible and even more practical than a RDBMS is most cases. RDBMSs require a schema definition whereas document databases tend to be conceptually schemaless. This is especially useful for user databases since you can add user information whenever you want without any migrations. For example this is perfectly valid :
{
id: <your UUID>,
name: "Willy",
email: "[email protected]"
},
{
id: <your UUID>,
name: "John",
facebookId: 10029823,
avatarUrl: "http:\\graph.facebook.com\picture\10029823
}
In other words, it offers quite a bit of flexibility. There are no significant downsides that I can think of.
In terms of CouchDB versus MongoDB the choice really depends on your personal preferences. CouchDB community and support is in somewhat of a decline whereas MongoDB's continues to grow. Personally I prefer MongoDB but it's safe to say CouchDB's API and overall design is somewhat cleaner.
Good luck.
Upvotes: 3