Запрос на проектирование базы данных

Question

Я делаю пустяк webapp, который будет содержать как автономные вопросы, так и 5+ вопросов. Я ищу предложения для проектирования этой модели.

Если викторина и ее вопросы хранятся в отдельных таблицах/объектах, с ключом для их связывания, или мне лучше создать викторину как автономную сущность со списками, хранящимися для каждой из характеристик вопроса? Или, возможно, у кого-то есть другая идея ...

Заранее спасибо. Вероятно, это поможет сказать, что я использую Google App Engine, который обычно хмурится реляционными версиями db, но я готов пойти своим путем, если это имеет смысл.

Answer 1

Вот дизайн, который будет учитывать наличие отношений «многие-ко-многим» между Quizess и Вопросами. Другими словами, у викторины может быть много вопросов, и вопрос может принадлежать многим викторинам. Существует только одна копия Вопроса, поэтому к ней могут быть внесены изменения, которые затем будут отражены в каждой викторине, к которой относится Вопрос.

class Quiz(db.Model): 
    # Data specific to your Quiz: number, name, times shown, etc 
    questions = db.ListProperty(db.Key) 

class Questions(db.Model): 
    question = db.StringProperty() 
    choices = db.StringListProperty() # List of possible anwsers 
    correct = db.IntegerpProperty() # index of string in choices that is correct 

Свойство вопросов объекта Quiz содержит ключ каждого объекта вопроса, который присваивается викторине. Быстрый поиск по ключевому слову и позволяет любому одному Вопросу присваиваться любому количеству индивидуальных викторин.

Answer 2

Трудно сказать без дополнительной информации, но имеющие следующие отношения было бы разумно, исходя из того, что вы сказали:

Quiz (id, title) 
Question (id, question, answer) 
QuizQuestion (quiz_id, question_id) 

Таким образом, вопросы могут появляться в различных викторинах.

Answer 3

У вас есть таблица вопросов, таблица опросов и таблица сопоставлений между ними. Это даст вам максимальную гибкость. Это достаточно просто, что вам даже не понадобится целая реляционная база данных система управления. Я думаю, что люди склонны забывать, что отношения - это довольно простые математические/логические концепции. RDBMS просто обрабатывает много грязной книги для вас.

Answer 4

Мой первый срез (я предположил, что вопросы были множественный выбор):

• Я бы таблицу вопросов, с ID_Question как ПК, текст вопроса и категории (если вы хотите) ,
• У меня была бы таблица ответов с ID_Answer как ПК, QuestionID как FK обратно в таблицу «Вопросы», текст ответа и флаг о том, правильный ответ или нет.
• У меня будет таблица опросов, с ID_Quiz как ПК, описание викторины и категория (если хотите).
• У меня будет таблица QuizQuestions с ID_QuizQuestion как ПК, QuizID как FK обратно в таблицу Quizzes и QuestionID как FK обратно в таблицу «Вопросы».

Эта модель позволяет:

• Задавайте вопросы автономные или в викторинах
• Позволяет иметь много или несколько вопросов в викторине, как вы хотите
• Позволяет иметь как многие из немногих выбор вопросов по вашему желанию (или даже несколько правильных ответов)
• Использование вопросов в нескольких викторинах

Answer 5

Недавно я завершил приложение App Engine для того, чтобы принимать индивидуальные викторины.

Я бы сказал, пройдите по простому маршруту и ​​сохраните все о каждой викторине в одном субъекте викторины.Если вам не нужно повторно использовать вопросы между викторинами, не нужно искать или в любом другом доступе способа структуры викторины, кроме принимая викторину, вы можете просто сделать:

class Quiz(db.Model): 
    data = db.TextProperty(default=None) 

Затем данные может быть структура JSON, подобная:

data = { 
    "title" : "Capitals quiz", 
    "questions" : [ 
     { 
      "text" : "What is the capital of Finland?" 
      "options" : ["Stockholm, Helsinki, London"], 
      "correct" : 1 
     } 
     ... 
    ] 
} 

Вещи, для которых вам нужны индексы, которые вы хотите оставить из этой структуры данных. Например, в моем приложении я обнаружил, что мне нужно оставить идентификатор создателя викторины вне данных, чтобы я мог сделать запрос хранилища данных для всех викторин, созданных определенным человеком. Кроме того, у меня есть дата создания вне данных, поэтому я могу запросить последние викторины.

created = db.DateTimeProperty(auto_now_add=True) 

Возможно, у вас есть другие поля. Как я уже сказал, это очень простой способ хранения викторин, без необходимости иметь несколько объектов хранилища данных или запросы для викторины. Тем не менее, он хорошо зарекомендовал себя на практике в моем приложении для тестирования личностей и является все более популярным способом хранения данных.