I'm a born and bred relational database guy and C# programmer dude. IBM DB2 & VB.Net in school. TSQL & C# at work.

I'm planning a project for fun: Designing a Testing platform that goes from DB through application/website.

When you think of "Exam" or "Test" Questions/Answers, there are many question types (not my picture, but good example of the multitude of question types):

Question Types

I want:

  • Test (ex: Comptia A+)
  • Classification of question (This question meets objective or domain X of test Y. Test Y needs 3 questions for domain X.)
  • Multiple question types (not necessarily limited to those in the picture above)
  • Notes about correct/incorrect answers (This is why ___ is correct. Reference link here.))
  • History/reversioning

I know I can do all of this in Sql Server, but I don't feel as if it would be the most efficient choice. I can't bring myself to like options that come to mind: Tables per question type. EAV tables. Embedded data structures of some sort.

I've never felt the need to learn "NoSQL" and was wondering if there are any "platforms" that would be a stronger candidate for this than TSQL? Or should I stick to what I know and do what it takes to make it work in a traditional RDBMS?


Using an RDBMS is fine, but the sticky part is how to store the parameters needed to render each type of question.

I would caution against having separate table definitions (or lots of type-specific columns) for each type of question. While these details (such as the list choices for a multiple-choice question) can be seen through a relational lens, it would, IMHO, be overkill to try to do so.

Instead, I would suggest having a simpler Question table design for that is agnostic to the type of question (other than a field indicating the type, of course), and store the information that is specific to the question type (a list of choices for a multiple-choice question and which is correct, etc.) in an xml field (or a varchar() with JSON, HTML, or some other semi-structured format that meets your needs).

This will allow you to add and refine the supported question types without having to change the table definitions, and CRUD operations for every question type will be essentially the same. So you get the flexibility of a NOSQL approach for the portions of your model that are quite variable without losing the relational structure of the tests and questions overall.

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.