I have a HTML form which sends the results to a database currently. The questions are hardcoded to the html page and I am trying to make the form more scalable, dynamic and flexible.
I got suggested that I should have different tables for the questions, choices and submitted answers. I sketched out a layout in Excel and now I have written scripts for creating the tables but I am still facing a problem with the question_choiceX columns. What if someone needs to make a questions that has 36 possible answers? Or 100? Those are probably rare scenarios but I acknowledge that I can't ignore them when creating the database or I might run in to big problems later.
Since SQL doesn't have arrays, I have been thinking hard and I've realized one possible solution but I am not sure if it would be good practice, and it's not perfect either:
- Making the
question_choiceXcolumns into only a singlequestion_choicescolumn which is aFOREIGN KEYthat refers to another table dedicated for all of the possible choices of that single question. I'd imagine this not to be very optimal because then I might end up with an enormous amount of tables. And this doesn't help either if I need to add more answer choices to a question afterwards.
These are many-to-many relationship.
Have a table of questions. (One row per question).
Have a table of answers. (One row per answer). (You only need one table of answers, not one per question).
Have a bridge table between them which associates the answers with the question they are for.
Have a table of users or a table of attempts to answer the questions.
Have a bridge table between that and the answers.
Bridge tables generally have two foreign keys, one onto each of the tables they are bridging. You might use those two foreign keys as a composite primary key for the bridge table itself.