Question

I am in the process of writing a web-based quiz application using PHP and MySQL. I don’t want to bore you with the details of it particularly, so here’s what (I think) you need to know.

Questions are all multiple choice, and can be stored in a simple table with a few columns:

1. ID: The question number (primary index)
2. Category: The category this question falls under (e.g. animals,
   vegetables, minerals)
3. Text: The question stem (e.g. What is 1+1?)
4. Answer1: A possible answer (e.g. 2)
5. Answer2: A possible answer (e.g. 3)
6. Answer3: A possible answer (e.g. 4)
7. CorrectAnswer: The correct answer to the question (either 1, 2 or 3 (in this case 1))

Users can sign up by creating a username and password, and then attempt questions from categories.

The problem is that the questions I’m writing are designed to be attempted more than once. However, users need to be given detailed feedback on their progress. The FIRST attempt at a question matters, and contributes to a user’s overall ‘questions answered first time’ score. I therefore need to keep track of how many times a question has been attempted.

Since the application is designed to be flexible, I would like to have support for many hundreds of users attempting many thousands of questions. Thus, trying to integrate this information into the user table or questions table seems to be impossible. The way I would like to approach this problem is to create a new table for each user when they have signed up, with various columns.

1. Table Name: A user’s individual table (e.g. TableForUser51204)
2. QuestionID: The ID of a question that the user has attempted.
3. CorrectFirstTime: A boolean value stating whether or not the
   question was answered correctly first time.
4. Correct: The number of times the question has been answered
   correctly.
5. Incorrect: The number of times the question has been answered
   incorrectly.

So I guess what I would like to ask is whether or not organising the database in this manner is a wise thing to do. Is there a better approach rather than creating a new table for each user? How much would this hinder the performance if there are say 500 users and 2000 questions?

Thanks.

Answer 1

You don’t want to be creating a new table per user. Instead, modify your database structure.

Normally, you’d have a table for questions, a table for options (with maybe a boolean column to indicate if it’s the correct answer), a users table, and a join table on users and options to store users’ responses. A sample schema:

CREATE TABLE `options` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `question_id` int(10) unsigned NOT NULL,
  `text` varchar(255) NOT NULL,
  `correct` tinyint(1) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `question_id` (`question_id`)
) TYPE=InnoDB;

CREATE TABLE `options_users` (
  `option_id` int(10) unsigned NOT NULL,
  `user_id` int(10) unsigned NOT NULL,
  `created` timestamp NOT NULL,
  KEY `option_id` (`option_id`),
  KEY `user_id` (`user_id`)
) TYPE=InnoDB;

CREATE TABLE `questions` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `question` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`,`question`)
) TYPE=InnoDB;

CREATE TABLE `users` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(60) NOT NULL,
  `password` char(40) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `username` (`username`)
) TYPE=InnoDB;


ALTER TABLE `options`
  ADD CONSTRAINT `options_ibfk_1` FOREIGN KEY (`question_id`) REFERENCES `questions` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `options_users`
  ADD CONSTRAINT `options_users_ibfk_2` FOREIGN KEY (`option_id`) REFERENCES `options` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  ADD CONSTRAINT `options_users_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

This links options to questions, and users’ responses to options. I’ve also added a created column to the options_users table so you can see when a user answered the question and track their progress over time.