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.