5

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.

Improve this question
5

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!

Improve this answer
4
  • Thank you, I appreciate the thorough response! Was wondering if you maybe could update it to add your thoughts on an additional concern: with a NoSQL solution (particularly RavenDB), to an extent my objects become my schema and can adjust as necessary. I have to build that in SQL server first (unless I go with Entity Framework). Thoughts on this aspect? – SeanKilleen Nov 16 '12 at 2:18
  • That is a good question, I have my opinions on the matter but it is not an educated opinion. I will ping one of our devs to see what they think about it. We were an early adopter on Entity Framework but the early versions were a nightmare to work with (at least for us it was), these days it has gotten much better. If anyone has immediate answers to address this I'd be curious to know! Personally I have always dealt with schema changes as a 'necessary evil' and just bit the bullet, probably limiting myself to better solutions. – Ali Razeghi Nov 16 '12 at 2:52
  • I asked one of our architects opinions. She stated that we were using Entity Framework 2.0 and shared our sentiment that was not very mature, the new versions are better but fundamentally we have the same problem, a lot of which I personally was hired to fix. With EF it generates largely raw SQL, sprocs aren't really used and it increases a lot of security (SQL Injection Heaven) and performance issues. It makes it hard to profile and performance tune down the line. Same with LINQ which we used. Forget getting PCI certified on it. On a small scale where these things dont matter, use it. – Ali Razeghi Nov 16 '12 at 21:29
  • @Seankillean what option you chose? i had just done a similar app using SQL server. the app answers could grow to millions of rows in answer table, but reporting can be done as a separate tool. Displaying Questions / Answer for a particular survey wont be slow as you already know surveyid, question id etc. and can put a index. – Usama Khalil Feb 5 '18 at 6:40
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.