多人/单测验游戏的数据库设计

Question

我在这里看到了很多问题，但是没有人适合我的问题。我正在尝试创建可扩展的ER模型，并且如果我想添加更多数据，几乎不会破坏任何东西，所以我试图创建的是：

有两种类型的用户，例如Admin和Worker，它们具有不同的角色。

管理员可以对问题进行CRUD，也可以创建一个房间，用户可以在其中加入在一起玩耍（这只是一个名字，就像Kahoot！一样），但是在其中创建更多属性可能是一个好主意。就像，世卫组织正在这个房间里玩，给大家一点，但是等我给你看一下设计之后再说吧。

好的，我的设计是：

包含以下内容的表用户：

_id
username
password
date_creation

这是默认值，但是我想知道如何定义角色（如果它是Admin或Worker），例如isAdmin：true，然后检查此Bool？或者我可以创建另一个角色表，并将其连接到用户表？

但是也许我必须为两者创建一个表，我的意思是，有一个管理员，该管理员具有密码和一些功能，然后还有一个名为Worker的用户，该用户具有另一个密码和其他功能。

然后我要在Question表中包含：

_id
question_name
answers[1,2,3,4]
correctAnswer or answers because it can be multi option chooser
topic
isExamQuestion
dificulty

然后“房间”表应包含：

_id
name
capacity
type (game can be as a group or solo) that's why this attribute
exam (This should be a flag to know if this question is for an exam or not (It can be for EXAM or PRACTISE)
ranking (This is the top X from 1 to X)
don't think if I have to add the winner here because if I get the position 0 from ranking I get the winner...

还有一个名为Topic的表，如果我的问题有一个主题，那么我可以按Topic选择问题。主题的示例应该是数学，以便用户只能进行考试或使用数学问题进行测试。

_id
Name
Questions[...]
Then I have to store like a historic about what are the questions worker has answered correct and what did not, to make some statistics, but I need to store some historicals for Admin to see in this topic the average that Workers have failed more is : Question23 (for instance) something like that.

我所缺少的，您能尝试帮助我弄清楚如何使这种设计更好吗？

注意：我在服务器端使用Spring，在前端使用Angular，在App中使用Android，但是我可以更改所有内容以更快/更好地使用此数据库。

编辑

如果您需要更多详细信息并且我的解释不正确，那么游戏就顺畅了。

管理流程

1. 创建问题（具有不同答案，例如是/否，带有复选框（单答案和多答案），文本等...）
2. 创建一个“游戏”，工人可以加入其中（这主要是编程方面的东西），但它应该是一个具有属性的房间，例如房间的ID，maxNumber，类型（考试）和存储历史记录，还有一个类型游戏（例如图像，视频等）
3. 查看有关Workers的统计信息，这意味着查看他们回答了正确，失败的答案的数量，每个主题都可以看到（这就像联接和填充，但是必须做好设计）
4. 通过所有信息（参与者，分数，时间，资料）查看他之前参加的考试的历史记录

工作者流为

他可以练习意味着他可以随机或按主题回答问题（应保存每个答案以供统计，并避免重复回答正确的问题），他也可以进行考试（而非多人），这只是管理员可以选择的选项检查问题是否属于考试的一部分。

然后是房间的东西，他可以加入ID。

如果您需要进一步说明，请告诉我，我会尽快给您答复。

Answer 1

实际上，您的系统具有三个逻辑部分（模块）：

• 包含用户数据并实现身份验证和用户操作授权的用户模块
• 调查问卷模块，其中包括问题和答案的管理
• 调查问卷历史记录模块，其中包含每个用户的历史记录

这些模块的数据库设计如下所示

用户模块：

角色-包含系统中的用户角色

• id-角色的唯一标识符
• 名称-角色名称，例如admin，worker等。

用户-包含用户和有关分配给他们的角色的信息

• id-用户的唯一标识符
• 用户名
• 密码
• role_id-角色已分配给用户的标识符

问号模块：

主题-包含问题主题

• id-主题的唯一标识符
• 名称-主题名称

问题-包含问题

• id-问题的唯一标识符
• topic_id-问题的主题标识符
• 文本-问题内容
• is_exam_question-是否考题
• 类型-答案的类型（布尔，复选框等）
• 困难

答案-包含所有问题的答案

• id-答案的唯一标识符
• question_id-包含答案的问题的标识符
• 文本-问题内容
• is_correct-表示答案是对还是错的标志

房间-包含有关房间的信息

• id-朗姆酒的唯一标识符
• 名称-朗姆酒的名称
• 容纳人数-可以加入会议室的最大工人人数
• 类型-房间类型：团体，独奏等。
• learing_type-房间类型：考试，练习等。

user_in_room -包含有关加入会议室的用户的信息

• user_id-已加入会议室的用户的标识符
• room_id-房间的标识符
• 得分-会议室中用户的当前得分

历史模块：

user_question_history -包含有关用户回答的问题的信息

• user_id-用户的标识符
• room_id-用户回答问题的房间的标识符
• question_id-用户回答的问题的标识符
• 得分-用户按问题得分

user_answer_history -包含有关用户选择的答案的信息

• user_id-用户的标识符
• room_id-用户回答问题的房间的标识符
• question_id-用户回答的问题的标识符
• answer_id-用户选择的答案的标识符

使用此架构可以构建不同的报告。例如，您可以按房间显示所有用户的结果

SELECT r.id,
    r.name,
    u.username,
    ur.score
FROM room as r
LEFT JOIN user_in_room as ur ON ur.room_id = r.id
LEFT JOIN user as u ON u.id = ur.user_id
WHERE r.id = <id>

或者您可以查看有关用户答案的​​详细信息

SELECT 
    q.text,
    a.text
FROM user_in_room as ur ON ur.room_id = r.id
LEFT JOIN user_question_history as uqh ON ugh.user_id = ur.user_id AND ugh.root_id = ur.room_id
LEFT JOIN question as q ON q.id = ugh.question_id
LEFT JOIN user_answer_history as uah ON uah.user_id = ugh.user_id AND uah.room_id = ugh.room_id AND uah.question_id = ugh.question_id
LEFT JOIN answer as a ON a.id = uah.answer_id
WHERE ur.room_id = <id> AND ur.user_id = <id>

Answer 2

关于您的设计，我有两点看法：

第一：

您需要一个具有Profile和one-to-many表的User表，这样，如果要应用另一个特权，只需添加新的配置文件条目即可：

User表：

Id
Username
Fullname
Profile_id
...

Profile表：

Id
Name
Description

第二：

Exam和Question是many-to-many，要打破它，您将拥有第三张表Question_Exam：

Question_Exam：

 id_exam
 Id_Question
 Answer(provided)
 Id_user(taking the exam)
 IsCorrect(boolean, to avoid farther queries )
 date

Topic和Question是one-to-many

Question表：

 Id
 Name
 Answer(The correct one)
 Id_topic

其他结构都很好。

Answer 3

老实说，如果您确定现在和将来都只需要使用可能的类型，则在用户表中使用一个简单的bool isAdmin就能很好地工作。管理员所做的所有其他事情都可以从编程方面进行处理。无需堵塞您的数据库。

也就是说，如果您将来极少会有其他类型的用户，Maxim的答案就是前进的道路。这样，添加另一个角色，例如“ Editor”，就像将记录添加到“ Role”表一样简单。实际上，添加1000个新类型的用户就像将记录添加到“角色”表一样简单。因为您已经有了要查找角色的表，所以您的代码不必担心所有可能的用户类型（如果您有很多用户，这很麻烦），而不必担心它。数据库正在处理其余的事情。

Maxim答案的一个缺点是，在db中实现需要花费更多的工作，而要查看/更新用户的角色也需要更多的工作。

要在数据库中实现，您需要创建一个完整的额外表并确保其正确链接。这并不难，但是，特别是如果您不熟悉数据库，这是额外的工作，可能对您来说不值得。从维护的角度来看，这还意味着您还有另一个表可以保留选项卡。没什么大不了的，但还是要考虑一下。

从代码方面来看，这也会产生额外的琐事。例如，用户类型不再直接出现在用户表中，而是一个ID。这意味着当您想知道用户类型的名称时，您将不得不a）根据您拥有的ID在数据库中查询该用户类型，或者b）联接两个表，这有时会很棘手。更新角色也有类似的琐事。

同样，这些不是大问题，只是需要考虑的事情。如果只有两个可能的选择，则可能不值得进行额外的工作。

因此，简而言之，布尔值将起作用并且易于实现，但不可扩展。 Maxim的答案具有很强的可扩展性，使将来的扩展更加容易，但是实现和维护却有些困难。您必须做出自己喜欢的决定。