Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I currently have a planning tool using SQL tables that are sort of setup like this:

  • Date table (Contains dates & indicates if that day is a weekend / holiday etc)
  • Employee (Simple data)
  • Project (Simple data)
  • Assignments (Associates the three tables, key date + employee id + project id)

I have one SQL query that, for a specific month/year, a joined list of employees + dates + assignment, e.g. 01/01/2014 employee_1 project_1. In case of no assignments, it returned the date anyway, as this makes it the most manageable on the front-end.

I was toying around with node.js & mongodb for the first time today, and was wondering if my setup is something that could translate well to NoSQL.

I really like the idea of using the JSON notation all the way, but I figure that this might be one of those cases where I'm better off with a RDBMS?

share|improve this question

The number one thing that you should ask yourself: How big will data be?

NoSQL offers "collections" and easy data set which is a primary usage over traditional RBDMS. When I mean large I mean in the millions not thousands. An effective SQL can handle thousands if the design is proper. I have worked with large MySQL and when it is time to switch columns we got bounced by it so that is why we intermediately switch to NoSQL Mongodb solution but we are also still using RBDMS for other solutions like lookup tables. Thats my opinion.

Also please take a look at: When would someone use MongoDB (or similar) over traditional RDMS?

As your question have been debated before.

share|improve this answer
Your logic is reasonably sound, although your numbers are off by at least three orders of magnitude. I would expect a traditional RDBMS to readily handle millions of records. – Robert Harvey Mar 17 '14 at 17:07
Millions? I've managed billion row tables fine in MSSQL, you just have to design the tables right, and they'll churn reads and writes with perfectly good response times even in high load public facing production systems. I have personally seen this work fine in more than one job. So millions? Doesn't even scratch the surface of what an RDBMS can do. NoSQL has it's place and it's purpose, but just because you have lots of records doesn't mean you need NoSQL. – Jimmy Hoffa Mar 17 '14 at 17:11

Your Answer


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.