Take the 2-minute tour ×

I apologize if this belongs in web applications or something.

I'm creating a web application that is sort of a similar concept to github. Basically I plan to allow someone to create a design of something (lets say a recipe for a cake for instance) and they can add new ingredients (or from already existing, which will have attached calories, etc.). But I want to add in that revision control aspect, new versions, branches etc.. Also plan to allow cloning of a design.

That's a basic idea. But would those main functions of a revision-control-esque setup beg for nosql? Am I crazy and jumping into a hip looking db too fast?

Let me know if more details are necessary.

share|improve this question
SQL rocks. Use NoSQL if you have to (eg scale-out). Otherwise a traditional RDBMS sounds like what you need here. –  Jack Douglas Sep 29 '11 at 12:56
add comment

3 Answers

You certainly could do this but if revision control is what your after for documents use something like subversion or git. In general storing documents that do not depend on transactions and you are not storing sensitive information that requires immediate atomicy and consitency like financial transactions then a nosql solution may fit your needs and be appropriate.

To the best of my knowledge you'd have to be rolling your own in the revision diffs if that's something you're really looking for whether from a nosql or traditional sql solution.

Regardless, if you're working on something trivial and want to play around with newer technologies that you're unfamiliar with that's great, go for it.

At the same time, if this is for a commercial client and you aren't familiar with mongo, couch, etc it's probabaly better to stick with what you know and leave the sandbox for play time until you're ready.

share|improve this answer
Well I won't be tracking traditional documents, only fields from a web application form. Which is why I was planning to not just run each recipe through git. I'm not sure how much that really simplifies the issue of diffs –  jphenow Sep 29 '11 at 4:40
add comment

There is no problem to do this in a traditional relational SQL database. For revision control, you can have two tables, one with all current versions, and one with historical versions. When you want to add a revision of a record you could in a transaction do:

  1. insert the current revision into the historical table
  2. update the current table with the new revision

A traditional relational database are more flexible and easier to work with (compared to a NoSQL database), as long as you don't require your database to be on more than one server (e.g. for fault tolerance or horizontal scaling).

share|improve this answer
Good points. I think the cloning is what has me stuck on NoSQL - I'm trying to picture how I would take that historical table pointed at one user and make a clone of it that now points at different user. I have other hopes to allow remerging etc. but that may take some pondering –  jphenow Sep 30 '11 at 3:40
add comment

Sounds like a great project idea, and definitely a candidate for noSQL. MongoDB is right up there with the best. I have found it tremendously useful in my projects.

share|improve this answer
add comment

Your Answer


