1

许多用户可以创建许多事件。用户可以向所有者发送请求以参与该活动（作为候选人、选民或两者兼而有之）。当它是候选人请求时，其他详细信息将存储在候选人详细信息表中。

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)#如果请求类型为两者，则添加 2 个条目

CandidateDetails(id pk,u_id,e_id,candidate_image,candidate_promises)

Ballot(u_id,e_id,flag)#确保重复投票

4

3 回答 3

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)
于 2012-04-16T07:18:24.367 回答
0

候选人可以是用户吗？您不想排除它，然后您可以阻止他们对自己的事件进行投票。用户参与上下文应该独立于主题名称（candidate_details 是一个不好的选择，并且可能会限制未来对数据库的增强），保持你的语义干净——这只是一个风格上的建议，但它有助于全面，用户对事件的参与应该是记录在链接表中 user_vote (u_id,e_id,vote) user_participant (u_id,e_id,status(accepted,denied))

于 2012-04-16T07:23:43.027 回答
0

除了 userrequestpool 中的重复条目之外，您还可以再定义一个 request_type 或 r_id 对应于两者

于 2012-04-16T07:36:11.483 回答