Conception de base de données pour développer une application Web 'Quiz' en utilisant PHP et MySQL

Je voudrais commencer avec 4 tableau simple:

 * User
   - user_id    auto integer
   - regtime    datetime
   - username   varchar
   - useremail  varchar
   - userpass   varchar
 * Question
   - question_id   auto integer
   - question      varchar
   - is_active     enum(0,1)
 * Question_choices
   - choice_id        auto integer
   - question_id      integer
   - is_right_choice  enum(0,1)
   - choice           varchar
 * User_question_answer
   - user_id      integer
   - question_id  integer
   - choice_id    integer
   - is_right     enum(0,1)
   - answer_time  datetime

Mon bien que sur cette table design est:

• table User est pour le stockage de l'utilisateur enregistré.
• table Question est pour le stockage de toutes vos question. Il a is_active de sorte que vous pouvez choisir d'afficher uniquement actif en question (à l'aide de WHERE is_active = '1')
• table question_choices est pour le stockage de toutes les options disponibles. Il a is_right_choice qui définissent ce choix est la bonne réponse pour la question particulière.
• Table User_question_answer est pour le stockage de réponse de votre utilisateur. Il a is_right pour accélérer la recherche, pour voir si cette question et les choix de réponse est juste (basé sur is_right_choice définis précédemment). Il a également answer_time juste à noter lorsque l'utilisateur particulier de répondre à la question.

Ce fut aussi le premier projet que j'ai fait en PHP/MySQL il y a 8 ans.

Votre première solution est de code de la base de données pour correspondre exactement à votre formulaire. Si vous souhaitez enregistrer les utilisateurs et les quiz de moyens, donc ça va ressembler à quelque chose comme ceci:

CREATE TABLE users (
  username VARCHAR(16) PRIMARY KEY, 
  password VARCHAR(8), 
  email VARCHAR(255), 
  birthday DATE, 
  gender ENUM('M', 'F')
);

CREATE TABLE quiz_answers (
  username VARCHAR(16) REFERENCES users,
  question1 VARCHAR(10),
  question2 INT,
  question3 ENUM('YES', 'NO', 'MAYBE'),
  question4 BOOLEAN,
  question5 VARCHAR(25),
  submitted_at DATETIME,
  PRIMARY KEY (username, submitted_at)
);

Donc, c'est juste l'enregistrement au strict minimum: l'utilisateur et le test des mémoires. J'ai les types de donnée pour les réponses que vous devrez faire spécifique à votre questionnaire. J'ai aussi fait une réponse assortie de l'utilisateur et le moment où ils se sont soumis; vous êtes plus susceptibles d'utiliser une clé de substitution (AUTO_INCREMENT), mais je tiens à résister à des mères porteuses autant que possible.

Droit au large de la chauve-souris il y a un 1FN violation: questionN. Si vous faites ce droit, vous le nom de ces colonnes après ce qu'ils signifient, et pas seulement de la question à laquelle ils sont. Mais la normalisation c'est vraiment la prochaine étape vers les formes qui sont extensibles, mais l'histoire de la piste.

La prochaine chose que vous remarquerez est que vraiment un jeu est un ensemble de questions, dont chacune a une collection de réponses possibles. Et puis la soumission d'un formulaire de vraiment se rapporte d'une sélection de réponses à leurs questions, sur un quiz de forme, par un particulier quiz de l'utilisateur. Cela sonne comme une quatre voies de la relation: l'utilisateur, quizz, question, réponse. Vous pouvez couper un de ces si vous n'avez pas l'esprit de répéter des questions sur les différents quiz, mais par souci d'exhaustivité, nous allons aller en bas de cette route. Remplacer quiz_answers ci-dessus:

CREATE TABLE questions (
  id INTEGER AUTO_INCREMENT PRIMARY KEY,
  question TEXT
);

CREATE TABLE answers (
  id INTEGER AUTO_INCREMENT PRIMARY KEY,
  question_id INTEGER REFERENCES questions,
  answer VARCHAR(255)
);

CREATE TABLE quizzes (
  name VARCHAR(255) PRIMARY KEY,
);

Nous n'avons pas vraiment des métadonnées pour un test, si c'est juste un nom pour l'instant.

Alors maintenant, vous avez besoin d'un un-à-plusieurs relation de questions, de réponses et de questionnaires à questions.

CREATE TABLE question_answers (
  question_id INTEGER REFERENCES questions,
  answer_id INTEGER REFERENCES answers,
  idx INTEGER,
  PRIMARY KEY (question_id, answer_id)
);

CREATE TABLE quiz_questions (
  quiz_name VARCHAR(255) REFERENCES quizzes,
  question_id INTEGER REFERENCES questions,
  idx INTEGER,
  PRIMARY KEY (quiz_name, question_id)
);

La partie la plus délicate, comme mentionné ci-dessus, est le plus élevé de l'ordre de la relation entre l'utilisateur et la soumission du formulaire, et le lien de la forme de questions à l'utilisateur les réponses. J'ai décidé de le séparer en deux tables pour éviter des répétitions.

CREATE TABLE quiz_submissions (
  id INTEGER AUTO_INCREMENT PRIMARY KEY,
  username VARCHAR(16) REFERENCES users,
  quiz_name VARCHAR(255) REFERENCES quizzes,
  submitted_at DATETIME
);

CREATE TABLE submission_answer (
  submission_id INTEGER REFERENCES quiz_submissions,
  question_id INTEGER REFERENCES questions,
  answer_id INTEGER REFERENCES answers,
  PRIMARY KEY (submission_id, question_id)
);

C'est assez bien de rectifier ce point. Vous pouvez voir que c'est aussi un peu plus difficile de requête. Pour obtenir toutes les questions pour le quiz, vous devrez joindre à partir du questionnaire les questions. Vous pouvez rejoindre à partir de là, sur les réponses à faire une grosse requête pour obtenir toutes les données dont vous avez besoin pour construire la forme (avec avoir à faire plus de post-traitement) ou vous pouvez frapper la base de données de plus de temps pour chaque question et de faire moins de post-traitement. Je peux argumenter. Pour obtenir l'intégralité d'un des utilisateurs de réponses, vous allez avoir à sélectionner à partir de user_submissions avec le quiz de l'ID et le nom d'utilisateur de la submission_answer tableau de la question et la réponse que l'utilisateur a choisi. Si l'interrogation va devenir intéressant rapidement. Vous allez perdre votre peur de jointures, si vous en avez un.

J'espère que ce ne sera pas vous mettre hors de bases de données relationnelles trop; en faisant cela, vous êtes, en effet, de faire d'un modèle relationnel à l'intérieur du modèle relationnel, mais une forme restreinte.

Je me rends compte à l'aide d'une beaucoup de naturel clés comme j'ai fait ci-dessus est un peu orthodoxes de ces jours. Cependant, je vous recommande de l'essayer, au moins pendant que vous êtes à la mise en route, car il sera beaucoup plus facile de voir comment les jointures doivent travailler si ils ne sont pas tout entiers dans la plage de 1 à 10.