Should I use SQL or NoSQL for this specific design (surveys)?

Question

Building a small web application to create satisfaction surveys with a default list of questions and responses. The application is for a small audience of people (5,000 max) with surveys sent out when work orders are completed.

Given the small size and relatively simple requirements, I'm thinking I could utilize either a SQL or NoSQL solution (I have easy access to both).

Types of entities

• Survey Templates (probably 3 of them)
• Questions (multiple questions per survey template)
• Question Types (free form, specific-choice responses, etc.)
• Survey Responses (the responses to the questions on a specific survey template)

Querying / Reporting Needs

• display responses of individual surveys
• display aggregated responses across a range of surveys by certain aspects
  • work order # (multiple surveys per work order)
  • date range of work orders
  • group that performed the work

Change/Growth Needs

• Survey templates, template questions, and possible responses can potentially change at any given time (dictated by the customers and evolving)
  • could conceivably create a new template when necessary but would be great to not have to do that where applicable.
• No worry about growth in terms of storage. This is currently being done with a (horribly designed) Access DB and so we're not talking anything major here.

Other Needs

• Structure should be able to accommodate requiring more information / notes if the responses are below a certain threshold (E.g. 3 or below out of 5)

Stack Considerations

• This is being built on the Microsoft ASP.NET stack (MVC4, WebAPI, etc.)

Personal Preferences / Thoughts

• I've wanted to work with NoSQL databases more for a while
• I am more familiar with SQL databases but it seems like a lot of schema and server overhead for something like this
• RavenDB and CouchDB are both appealing to me for this
  • Raven moreso because it's built so nicely to work with .NET and via HTTP, but I'm not sure if the licensing will work out.
  • Would also consider MongoDB, but I was thinking straight JSON docs might be easier to work with than BSON
• with a NoSQL solution (particularly RavenDB), to an extent my objects become my schema because I'm persisting them to a data store. I have to build that structure in SQL server first (unless I go with Entity Framework). Does this lend an advantage to NoSQL or is it a wash taking into consideration things like EF?

Interested in your thoughts and providing any information that would help someone make an objective decision.

Answer 1

Typically No-SQL solutions were implemented due to massive scale and not needing 100% ACID compliance. Flattening data out and de-normalizing it for performance gains were critical in getting us to where we are today with solutions such as GFS, Hadoop, Mongo, Basho RIAK, etc.

Your case doesn't scream No-SQL, if anything you'd probably be better served with MS SQL server since you're using the ASP.NET stack and MS SQL Server provides a lot of functionality with ASP.NET through CLR, powershell (which can also call .Net objects) and playing very nice with IIS (I assume you'll also be hosting it on IIS). This also sounds like something you can use SQL Server 2012 Express thus saving licensing costs.

MS SQL Server will also let you easily 'join' data across non related tables in cases where you come up with a new idea, and on a No-SQL solution that would be more difficult to implement.

But in reality, looking at your requirements and what you're going to be using it for. You can go either way. If it makes you happier to use a No-SQL solution and get your feet wet, awesome! Go for it! End result probably won't matter, but to strictly answer the question, which is better for a .Net app with the usage patterns you described, I'd personally go with SQL 2012 Express.

I'm curious to see what others think!

Answer 2

Yes, you don't need a NoSQL database. As the earlier answer said, you don't have a scale issue. Moreover you have requirement for a richer query set. NoSQLs don't offer a very rich query capabilities. If you normalize your database schema, the future requirements can be properly accommodated by adding more tables. NoSQLs specialize in having loose schema within the same table (or whatever is equivalent to it, like column family etc)

If you want to try NoSQL for the fun of it or to learn it, you can do that. You don't need to forcefully wed your curiosity with your requirements.