0

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?

Busata
  • 101

1 Answers1

-4

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 a Relational DBMS?

As your question have been debated before.