Multiplayer/Single 问答游戏的数据库设计
Database Design for a Multiplayer/Single Quiz game
我在这里看到了很多问题，但没有一个适合我的问题。我正在尝试创建一个可扩展的 ER 模型，如果我想添加更多数据，几乎不会破坏任何东西，所以我要创建的是：
有 2 种类型的用户，假设是 Admin 和 Worker，他们有不同的角色。
管理员可以对问题进行 CRUD，也可以创建一个房间供用户加入一起玩（这只是一个名称，类似于 Kahoot！），但创建更多属性也许是个好主意在里面，谁在这个房间里玩，给每个人打分，但是等我给你看设计的时候再说吧。
好的，在我的设计中我有：
Table 用户包含：
_id
username
password
date_creation
这是默认的，但我想知道如果角色是管理员或工作人员，我该如何定义角色，例如 isAdmin:true 然后我检查这个 Bool？或者我可以创建另一个 table 角色并将其连接到用户 table?
但也许我必须为两者创建一个 table，我的意思是有一个具有密码和一些功能的 Admin，然后是具有另一个密码和其他功能的用户 Worker。
然后我想要问题 table 其中包含 :
_id
question_name
answers[1,2,3,4]
correctAnswer or answers because it can be multi option chooser
topic
isExamQuestion
dificulty
那么房间 table 应该包含：
_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...
还有一个 table 命名的主题，如果我的问题有主题，那么我可以 select 按主题提出问题。主题的一个例子应该是数学，这样用户就可以只做考试或用数学问题做测试。
_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，应用程序使用 Android，我可以更改任何内容以使用 faster/better虽然这个数据库。
编辑
如果您需要更多详细信息并且我的解释有误，请查看游戏流程。
管理流程
- 创建问题（具有不同类型的答案，如 True/false、复选框（单选和多选）、文本等...）
- 创建一个 "game" 工人可以加入的地方（这主要是编程的东西）但它应该是一个有属性的房间，比如房间的 id、maxNumber、类型（考试）和存储历史记录，还有一种游戏（比如图片、视频等）
- 查看有关 Workers 的统计信息，这意味着查看他们回答正确、失败的答案数量，查看每个主题（这就像连接和其他东西，但必须做好设计）
- 查看他之前进行的所有信息（参与者、分数、时间、资料）的历史考试
并且 Worker 流程是
他可以练习意味着他随机或按主题回答问题（每个答案都应保存以供统计，以避免重复他正确回答的问题），他也可以做考试（不是多人游戏）只是一个选项管理员可以检查问题是否是考试的一部分。
然后房间的东西，他可以用Id加入。
如果您需要进一步说明，请告诉我，我会尽快回复您。
实际上，您的系统具有三个逻辑部分（模块）：
- users 模块，包含用户数据并实现用户操作的身份验证和授权
- 包含问题和答案管理的调查问卷模块
- 调查问卷历史模块，包含每个用户的历史
这些模块的数据库设计如下
用户模块：
角色 - 包含系统中的用户角色
- id - 角色的唯一标识符
- name - 角色名称，例如admin、worker等
用户 - 包含用户和有关分配给他们的角色的信息
- id - 用户的唯一标识符
- 用户名
- 密码
- role_id - 角色分配给用户的标识符
问卷模块：
主题 - 包含问题主题
- id - 主题的唯一标识符
- name - 主题名称
问题 - 包含问题
- id - 问题的唯一标识符
- topic_id - 问题的主题标识符
- text - 问题内容
- is_exam_question - 是否考题
- type - 答案类型（布尔值、复选框等）
- 难度[=104=]
answer - 包含问题的所有答案
- id - 答案的唯一标识符
- question_id - 包含答案的问题标识符
- text - 问题内容
- is_correct - 表示答案为真或假的标志
房间 - 包含有关房间的信息
- id - 朗姆酒的唯一标识符
- 名称 - 朗姆酒的名称
- capacity - 可以加入房间的最大工人数
- type - 房间类型：团体、单人等
- learing_type - 房型：考试、练习等
user_in_room - 包含有关加入房间的用户的信息
- user_id - 加入房间的用户标识符
- room_id - 房间的标识符
- score - 房间内用户的当前分数
历史模块：
user_question_history - 包含有关用户回答的问题的信息
- user_id - 用户的标识符
- room_id - 用户回答问题的房间标识符
- question_id - 用户回答的问题的标识符
- score - 问题的用户评分
user_answer_history - 包含有关用户选择的答案的信息
- user_id - 用户的标识符
- room_id - 用户回答问题的房间标识符
- question_id - 用户回答的问题的标识符
- answer_id - 用户选择的答案标识符
使用此模式可以构建不同的报告。比如可以按room
显示所有用户的结果
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>
你需要 Profile table 和 one-to-many 和 User table，这样如果你想申请另一个权限，只需添加新的配置文件条目：
User table:
Id
Username
Fullname
Profile_id
...
Profile table:
Id
Name
Description
Exam 和 Question table 与 many-to-many 相关，打破它你将有第三个 table 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 table:
Id
Name
Answer(The correct one)
Id_topic
其他结构没问题。
老实说，如果您确定只需要可能的类型——无论是现在还是将来——用户 table 中的一个简单的 bool isAdmin 就可以很好地工作。管理员所做的所有其他事情都可以从编程方面处理。无需阻塞您的数据库。
即便如此，即使您将来拥有其他类型的用户的可能性很小，Maxim 的答案也是可行的。这样，添加另一个角色（例如 "Editor,"）就像向 "Role" table 添加一条记录一样简单。事实上，添加 1000 个新类型用户就像在您的 "Role" table 中添加记录一样简单。因为您已经有一个要寻找角色的 table，所以您的代码不必担心所有可能的用户类型（如果有很多用户，这会很痛苦），只需考虑那些它需要。数据库正在处理其余部分。
Maxim 的答案的一个缺点是它需要更多的工作来在数据库中实现，并且需要更多的工作来 view/update 用户的角色。
要在数据库中实施，您需要创建一个额外的整体 table 并确保它已正确链接。这并不难，但是，特别是如果您是 dbs 的新手，这是一项额外的工作，对您来说可能不值得。这也意味着，从维护方面来说，您还有另一个 table 需要密切关注。没什么大不了的，但还是要考虑一下。
从代码方面来看，这也会产生额外的杂务。首先，用户类型不再直接在您的用户中 table--ID 是。这意味着当您想知道用户类型的名称时，您将不得不 a) 根据您拥有的 ID 查询该用户类型的数据库，或者 b) 加入 2 tables，这可以有时很棘手。更新角色也有类似的杂事。
同样，这些都不是大问题，只是需要考虑的问题。如果您只有两个可能的选择，那么额外的工作可能不值得。
因此，简而言之，布尔值可以工作并且易于实现，但不可扩展。 Maxim 的答案是相当可扩展的，使未来的扩展更容易，但有点难以实施和维护。您必须根据自己的喜好做出决定。
我在这里看到了很多问题，但没有一个适合我的问题。我正在尝试创建一个可扩展的 ER 模型，如果我想添加更多数据，几乎不会破坏任何东西，所以我要创建的是：
有 2 种类型的用户，假设是 Admin 和 Worker，他们有不同的角色。
管理员可以对问题进行 CRUD，也可以创建一个房间供用户加入一起玩（这只是一个名称，类似于 Kahoot！），但创建更多属性也许是个好主意在里面，谁在这个房间里玩，给每个人打分，但是等我给你看设计的时候再说吧。
好的，在我的设计中我有：
Table 用户包含：
_id
username
password
date_creation
这是默认的，但我想知道如果角色是管理员或工作人员，我该如何定义角色，例如 isAdmin:true 然后我检查这个 Bool？或者我可以创建另一个 table 角色并将其连接到用户 table?
但也许我必须为两者创建一个 table，我的意思是有一个具有密码和一些功能的 Admin，然后是具有另一个密码和其他功能的用户 Worker。
然后我想要问题 table 其中包含 :
_id
question_name
answers[1,2,3,4]
correctAnswer or answers because it can be multi option chooser
topic
isExamQuestion
dificulty
那么房间 table 应该包含：
_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...
还有一个 table 命名的主题，如果我的问题有主题，那么我可以 select 按主题提出问题。主题的一个例子应该是数学，这样用户就可以只做考试或用数学问题做测试。
_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，应用程序使用 Android，我可以更改任何内容以使用 faster/better虽然这个数据库。
编辑
如果您需要更多详细信息并且我的解释有误，请查看游戏流程。
管理流程
- 创建问题（具有不同类型的答案，如 True/false、复选框（单选和多选）、文本等...）
- 创建一个 "game" 工人可以加入的地方（这主要是编程的东西）但它应该是一个有属性的房间，比如房间的 id、maxNumber、类型（考试）和存储历史记录，还有一种游戏（比如图片、视频等）
- 查看有关 Workers 的统计信息，这意味着查看他们回答正确、失败的答案数量，查看每个主题（这就像连接和其他东西，但必须做好设计）
- 查看他之前进行的所有信息（参与者、分数、时间、资料）的历史考试
并且 Worker 流程是
他可以练习意味着他随机或按主题回答问题（每个答案都应保存以供统计，以避免重复他正确回答的问题），他也可以做考试（不是多人游戏）只是一个选项管理员可以检查问题是否是考试的一部分。
然后房间的东西，他可以用Id加入。
如果您需要进一步说明，请告诉我，我会尽快回复您。
实际上，您的系统具有三个逻辑部分（模块）：
- users 模块，包含用户数据并实现用户操作的身份验证和授权
- 包含问题和答案管理的调查问卷模块
- 调查问卷历史模块，包含每个用户的历史
这些模块的数据库设计如下
用户模块：
角色 - 包含系统中的用户角色
- id - 角色的唯一标识符
- name - 角色名称，例如admin、worker等
用户 - 包含用户和有关分配给他们的角色的信息
- id - 用户的唯一标识符
- 用户名
- 密码
- role_id - 角色分配给用户的标识符
问卷模块：
主题 - 包含问题主题
- id - 主题的唯一标识符
- name - 主题名称
问题 - 包含问题
- id - 问题的唯一标识符
- topic_id - 问题的主题标识符
- text - 问题内容
- is_exam_question - 是否考题
- type - 答案类型（布尔值、复选框等）
- 难度[=104=]
answer - 包含问题的所有答案
- id - 答案的唯一标识符
- question_id - 包含答案的问题标识符
- text - 问题内容
- is_correct - 表示答案为真或假的标志
房间 - 包含有关房间的信息
- id - 朗姆酒的唯一标识符
- 名称 - 朗姆酒的名称
- capacity - 可以加入房间的最大工人数
- type - 房间类型：团体、单人等
- learing_type - 房型：考试、练习等
user_in_room - 包含有关加入房间的用户的信息
- user_id - 加入房间的用户标识符
- room_id - 房间的标识符
- score - 房间内用户的当前分数
历史模块：
user_question_history - 包含有关用户回答的问题的信息
- user_id - 用户的标识符
- room_id - 用户回答问题的房间标识符
- question_id - 用户回答的问题的标识符
- score - 问题的用户评分
user_answer_history - 包含有关用户选择的答案的信息
- user_id - 用户的标识符
- room_id - 用户回答问题的房间标识符
- question_id - 用户回答的问题的标识符
- answer_id - 用户选择的答案标识符
使用此模式可以构建不同的报告。比如可以按room
显示所有用户的结果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>
你需要 Profile table 和 one-to-many 和 User table，这样如果你想申请另一个权限，只需添加新的配置文件条目：
User table:
Id
Username
Fullname
Profile_id
...
Profile table:
Id
Name
Description
Exam 和 Question table 与 many-to-many 相关，打破它你将有第三个 table 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 table:
Id
Name
Answer(The correct one)
Id_topic
其他结构没问题。
老实说，如果您确定只需要可能的类型——无论是现在还是将来——用户 table 中的一个简单的 bool isAdmin 就可以很好地工作。管理员所做的所有其他事情都可以从编程方面处理。无需阻塞您的数据库。
即便如此，即使您将来拥有其他类型的用户的可能性很小，Maxim 的答案也是可行的。这样，添加另一个角色（例如 "Editor,"）就像向 "Role" table 添加一条记录一样简单。事实上，添加 1000 个新类型用户就像在您的 "Role" table 中添加记录一样简单。因为您已经有一个要寻找角色的 table，所以您的代码不必担心所有可能的用户类型（如果有很多用户，这会很痛苦），只需考虑那些它需要。数据库正在处理其余部分。
Maxim 的答案的一个缺点是它需要更多的工作来在数据库中实现，并且需要更多的工作来 view/update 用户的角色。
要在数据库中实施，您需要创建一个额外的整体 table 并确保它已正确链接。这并不难，但是，特别是如果您是 dbs 的新手，这是一项额外的工作，对您来说可能不值得。这也意味着，从维护方面来说，您还有另一个 table 需要密切关注。没什么大不了的，但还是要考虑一下。
从代码方面来看，这也会产生额外的杂务。首先，用户类型不再直接在您的用户中 table--ID 是。这意味着当您想知道用户类型的名称时，您将不得不 a) 根据您拥有的 ID 查询该用户类型的数据库，或者 b) 加入 2 tables，这可以有时很棘手。更新角色也有类似的杂事。
同样，这些都不是大问题，只是需要考虑的问题。如果您只有两个可能的选择，那么额外的工作可能不值得。
因此，简而言之，布尔值可以工作并且易于实现，但不可扩展。 Maxim 的答案是相当可扩展的，使未来的扩展更容易，但有点难以实施和维护。您必须根据自己的喜好做出决定。