DB Model schema for questions

[anurag-majumdar]

I have set the schema as:

questions: [ { question: { type: String }, answer: { type: String } } ], options: [ { type: String } ]

I took @ashwani99's schema as a reference to the following post: https://github.com/UdacityMobileWebScholarship/guess-quote/issues/36

questions: [ { question: "...", answer: "..."
}, ... ], options: [ 'optionone', 'optiontwo', ... ];

Previously, I thought of the following schema:

questions: [ { question: "...", options: ["....", "..."], answer: ["..."] }, // Continues ]

Let me know what you guys think? I can make changes accordingly if required. @danivijay @twishasaraiya @skyshader

[anurag-majumdar]

@danivijay @twishasaraiya @skyshader Hi guys, an update regarding the schema, I have updated the questions model to the following schema:

questions: [ { question: "...", options: ["....", "..."], answer: ["..."] }, // Continues ]

This is how it looks inside MongoDB:

[danivijay]

I think this will do. What do you think @twishasaraiya ?

[ishank-s]

Shouldn't the answer be a number type so that we don't need to do "option"===" answer" every time just check the value of answer wrt the number?

[ashwani99]

@prophet1996 No, options can be jumbled.

[ishank-s]

ok that makes sense then :)

[skyshader]

IMO again I believe that option should be referenced in the answer instead of having the complete option string as it's value. @twishasaraiya and @danivijay what are your thoughts?

[twishasaraiya]

I think since we are keeping our app simple for now we could go ahead with this. If anything better comes up then we could discuss it again.

[naveens239]

I too agree with what others have pointed out about having the value instead of string stored as answer. But keeping that aside - how are we feeding in the questions to the DB? Are we reading and converting and then storing via some script? Or are we manually feeding?

[skyshader]

I have another input we can think about here:

{
    question: '...',
    options: [
        {
            value: '...',
            isCorrect: true,
        },
        {
            value: '...',
            isCorrect: false,
        },
        {
            value: '...',
            isCorrect: false,
        }
    ]
}

With this approach we avoid matching options with answer and can directly send this object to frontend. For frontend, each option now knows if they are correct or not and we do not need to send states here and there and then match if option's value is similar to question's answer's value. Plus this can be extremely helpful for questions with multiple answers without having array of strings again for answers.

Let me know your thoughts @twishasaraiya @naveens239 and @ashwani99

[deveshjadon98]

I find @skyshader 's approach more scalable, Having a separate key for answer doesn't make sense. This way we'll send a question to UI along with it's options and show the correct options when users have submitted their responses.

[deveshjadon98]

@twishasaraiya we can't keep such things for future iterations, A scalable schema should be defined during first iteration only. It will only make our job easier.

[twishasaraiya]

@deveshjadon98 Well if you are talking about scalability then I agree that current model is not so good. Since I have only worked on small personal projects where it was just to learn new stuff. Anyways,then I guess @skyshader model looks better option.

[skyshader]

@deveshjadon98 would you like to submit a PR then, if everyone is on the same page? :)

[deveshjadon98]

@skyshader Sure, let me implement these changes.

[anurag-majumdar]

@skyshader @deveshjadon98 Great thought on the model. Really needed a refinement on the older one. After all, a schema design does need to go through some thought despite the scalability of the application. Database really makes it easy for us. Good going guys! 👍

[naveens239]

@twishasaraiya @skyshader @deveshjadon98 @danivijay How are we feeding the data to the DB? I can make the necessary changes and convert to json format. Let me know.

[skyshader]

Yes @naveens239 , json equivalent to the schema would be amazing. We can create a seeder that will insert the data into mongodb via our models.

[suhasbansude]

I have input for que model { "queId" : "", // Unique Guid "queString" : "", "level" : "", //EASY,MEDIUM,HARD "type" : "", // Single Select ,Multiple Select "options" : [ { "optionId" : 1, "optionString" : "" "sequence" : 1 } ], answer : [{ "optionId" : 1, "optionString" : "" }], isActive : true }

[skyshader]

The level and type are not in the plan as of now. But our current model just needs those two fields type and level later when we need it :)

[naveens239]

@skyshader With this approach { question: '...', options: [ { value: '...', isCorrect: true, }, { value: '...', isCorrect: false, }, { value: '...', isCorrect: false, } ] } I will convert the questions and answers to json format. Is that fine? Let me know

[skyshader]

question: {
  title: {
    type: String,
    default: null
  },
  options: [
    {
      value: {
        type: String,
        default: null
      },
      is_correct: {
        type: Boolean,
        default: false
      }
    }
  ],
}

[naveens239]

What the "type" and default?

[skyshader]

@naveens239, ignore those... I posted this to give you the main attributes key values so you could use them in the json. Like instead of question: ... use title: ... and so :)