许多用户可以创建许多事件。用户可以向所有者发送请求以参与该事件（作为候选人，选民或两者）。当它是候选请求时，其他详细信息将存储在候选详细信息表中。
User(u_id pk, username, password)
Event(e_id pk,u_id,e_name,e_date)
UserRequestPool(urp_id pk,u_id,e_id,request_type)＃如果请求类型都是
CandidateDetails(id pk,u_id,e_id,candidate_image,candidate_promises)
Ballot(u_id,e_id,flag)＃确保重复投票
答案 0 :(得分：1)
您应该将用户请求池ID存储在候选详细信息中，而不是事件ID和用户ID：
CandidateDetails (id pk, urp_id, candidate_image, candidate_promises)
投票表相同：
Ballot (urp_id, flag)
您可能希望将请求类型存储在表中：
UserRequestPool (urp_id pk, u_id, e_id, r_id)
RequestType (r_id, request_type)
答案 1 :(得分：0)
候选人可以是用户吗？你不想排除它，然后你可以阻止他们投票自己的事件。 用户参与上下文应该独立于主题名称（candidate_details是一个糟糕的选择，可能会限制未来对数据库的增强），保持你的语义清洁 - 这只是一个风格推荐，但它有助于全面，用户参与事件应该是记录在链接表中 user_vote（u_id，e_id，vote） user_participant（u_id，e_id，status（已接受，已拒绝））
答案 2 :(得分：0)
在userrequestpool中没有重复的条目，您可以定义一个对应于两者的request_type或r_id