Моя база данных нормализована?

Question

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

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) #adding 2 записи, если тип запроса и

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

Ballot(u_id,e_id,flag) # по обеспечению дубликата голосования

Answer 1

Вы должны хранить бассейн идентификатор запроса пользователя в деталях кандидата вместо события 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) 

Answer 2

Кандидат может быть пользователем? вы не хотели бы это исключать, и тогда вы можете помешать им голосовать за свои события. Контекст взаимодействия с пользователем должен быть независим от имени субъекта (кандидат_details является плохим выбором и может ограничить будущие улучшения базы данных), сохраните свою семантику в чистоте - это всего лишь стилистическая рекомендация, но она помогает всем, участие пользователя в событиях должно быть записаны в таблицах ссылок user_vote (u_id, e_id, голос) user_participant (u_id, e_id, статус (принято, опровергнутых))

Answer 3

istead из дублированных записей в userrequestpool, вы можете определить еще одну request_type или R_ID, что соответствует оба