Хранение викторины с несколькими вариантами в базе данных - выбор схемы

Я пытаюсь реализовать викторину с множественным выбором и хочу сохранить все свои вопросы и ответы в базе данных SQLite. У меня будет много вопросов, и для каждого вопроса будет отображаться 2 или более возможных ответа.

Мой вопрос: как мне хранить вопросы и ответы в базе данных? У меня есть две идеи для схемы (первичный ключ выделен жирным шрифтом)

как (многие для многих)

вопросы ( questionID: int, questionString: String, correctAnswerID: int)

ответы ( answerID: int, answerString: String)

questions_and_answers (questionID, answerID)

вопросы ( questionID: int, questionString: String, correctAnswerID: int)

ответы ( answerID: int, answerString: String, questionID: int foreign key)

Я не уверен, какой из них лучше, или есть другой способ?

Может быть, questions_and_answers станет очень большим и вызовет длительные времена поиска и проблемы с памятью? Опять же, я полагаю, что question_and_answers будет индексироваться на первичных ключах. Во второй схеме answers будет индексироваться на answerID, а не questionID? что означает, что время поиска увеличилось бы, поскольку всю таблицу нужно было бы искать?

Может быть от 10 000 до 20 000 ответов. (опрос может запускаться на мобильном устройстве, и вопросы необходимо будет показывать "мгновенно" )

Примечание. Я не ожидаю, что там будет много совпадений ответов между вопросами. Я бы не думал, что количество перекрытий будет означать меньшее количество хранимых данных, учитывая дополнительное пространство, требуемое таблицей questions_and_answers

Ответ 1

Вторая схема - лучшая, потому что она моделирует фактический домен: каждый вопрос имеет набор ответов. Даже если вы можете "сжимать" данные, сохраняя повторяющиеся ответы один раз, это не соответствует фактическому домену.

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

Схема 1 просто делает жизнь очень тяжелой.

Чтобы ответить на ваши вопросы по индексу, вам нужно добавить индекс на questionId. Когда у вас есть этот индекс, поисковые ответы на вопрос должны масштабироваться.

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

Если вам нужно найти более продвинутое хранилище (запросы, избыточность и т.д.), вы можете перейти к базе данных документов, например MongoDB или CouchDB.

Ответ 2

Кажется, что тупик (круговой цикл), поскольку столбец questionID упоминается как внешний ключ в таблице ответов, а столбец correctAnswerID называется внешним ключом в таблице вопросов.

Лучше создать столбец типа бит в таблице ответов, чтобы пометить правильный ответ и удалить столбец correctAnswerID.