дизайн базы данных для викторины с разными языками - PullRequest
0 голосов
/ 25 июня 2018

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

Вот как это выглядит сейчас (не стесняйтесь указывать на ошибки в дизайне):

* User:
   - id          PK
   - name
   - email
   - password

* Quiz
   - id          PK
   - slug
   - title

* Question
   - id          PK
   - quiz_id     FK
   - question
   - image
   - message

* Option
   - id           PK
   - question_id  FK
   - option
   - is_right

Relation between user and quiz to store results:

* Result
   - id           PK
   - user_id      FK
   - quiz_id      FK

* Result Details
   - id           PK
   - result_id    FK
   - question_id  FK
   - option_id    FK (The option user choose)
   - is_right

Тот же дизайн базы данных, но четкие связи между таблицами:

enter image description here

Моей первой мыслью было создать таблицу родительских языков для таблицы тестов (в языковой таблице много тестов):

* Language:
   - id          PK
   - language_title

* Quiz
   - id           PK
   - language_id  FK
   - slug
   - title

Но это только приведет к созданию языковой категории, и администратору придется создать совершенно новый тест для другого языка, а не просто добавить новый текст вопроса и текст опции.

Как мне спроектировать базу данных тестов для нескольких языков, чтобы только столбцы с текстом (заголовок, сообщение, вопрос и опция) могли получить новую запись вместо того, чтобы создавать новый тест?

Ответы [ 3 ]

0 голосов
/ 25 июня 2018

Прежде всего, вы должны пересмотреть свой выбор ключей.Ваш текущий дизайн (атомные суррогатные ключи везде ) допускает несогласованность повсюду.Если у вас нет дополнительных, не упомянутых ограничений для нескольких таблиц, вы можете, например, иметь один Result_detail, принадлежащий Вопросу A из Викторины B, но с Опцией, принадлежащей Вопросу C из Викторины D, а также Результатом, принадлежащим Викторине E.

И если у вас нет дополнительных, не упомянутых ключей, ваш дизайн допускает практические дубликаты.Например, вы можете иметь два идентичных Result_details, за исключением идентификатора, что может означать, что рассматриваемый пользователь дважды ответил на один и тот же вопрос в одном и том же результате.Это может быть функция, позволяющая пользователю пройти один и тот же тест несколько раз, но вы, вероятно, не хотите, чтобы несколько одинаковых (или разных, в этом отношении) ответов на один и тот же вопрос в рамках одного и того же результата теста.На самом деле, это довольно хороший пример того, как некритическое введение суррогатных ключей в некоторых случаях полностью пропускает точку ключей.

Result_details.Is_right выглядит избыточным.Можете ли вы получить Result_detail, который подходит, даже если его Option не установлен?

Есть и другие проблемы, кроме как ответить на ваш главный вопрос: если у вас фиксированное количество языков (особенно если все вопросы иу опций есть строки на всех языках), вы можете просто добавить столбцы с вопросами и опциями для каждого языка.Если кто-то кричит о первой нормальной форме, игнорируйте их (или попросите их формально определить 1NF).

Если у вас неограниченное количество языков, переместите столбцы Вопрос и Вариант в отдельные таблицы вместе сСтолбец языка и внешние ключи для таблиц Вопрос и Вариант соответственно.Например, используйте ISO 639 для значений столбца Language;таким образом, вам не обязательно нужна языковая таблица.

0 голосов
/ 27 июня 2018

Дизайн базы данных должен следовать из более общей модели информационного дизайна , полученной из концептуальной информационной модели , предпочтительно в формеДиаграммы классов UML (из-за их выразительности).Ниже приведена концептуальная информационная модель для вашей проблемы:

conceptual information model

Такая модель все еще должна быть обогащена подходящими стандартными атрибутами идентификаторов и типами данных для получениямодель информационного дизайна.Устраняя ассоциации и композиции (заменяя их ссылочными свойствами), мы получаем следующую модель классов OO, которая может использоваться в качестве основы для кодирования Java / C # / PHP / etc.классы:

OO class model

Обратите внимание, что мы добавили поддержку многоязычных тестов в этой модели классов OO, добавив перечисление IsoLanguageCode и класс TextItemс первичным ключом, состоящим из двух частей, состоящим из идентификатора текстового элемента и кода языка, так что опросы, вопросы и варианты ответа используют идентификатор текстового элемента для ссылки на текстовые элементы, используемые в качестве заголовка, текста вопроса и текста ответа.Также обратите внимание, что класс Quiz имеет производное свойство \availableLanguages, которое можно вычислить с помощью запроса, извлекающего все языки, для которых доступны текстовые элементы для всех вопросов теста и все варианты их ответов.

Модель проектирования базы данных SQL может быть получена из такой модели классов ОО путем замены ссылочных свойств соответствующими атрибутами внешнего ключа:

SQL database design model

0 голосов
/ 25 июня 2018

Я бы предложил этот общий маршрут:

1) Создать таблицу (перевод?) С полями language_id, string_id, value. Каждый string_id соответствует определенному сообщению независимо от языка. Таким образом, все string_ids x all language_ids = все возможные сообщения для разных переводов. Таким образом, (language_id, string_id) - это PK, а value - это то, что должен видеть ваш тестер.

2) Замените каждое текстовое поле в ваших таблицах на string_id.

3) Когда ваша среда представления должна показать string_id, она ВЫБРАЕТ его из таблицы, упомянутой в 1) ГДЕ language_id = тот, который выбран вашим тестером

...