Моделирование таблиц базы данных пользователей, групп и членства

Question

Я пытаюсь создать таблицы User, Group и Membership следующим образом. Пользователь может принадлежать к одной или нескольким группам, а в группе может быть один или несколько пользователей. Отношение «многие ко многим» между таблицей «Пользователь» и «Группа» поддерживается с использованием таблицы «Членство». Я хотел бы сохранить статус участника (утвержден / ожидает / что-то еще?) И информацию об утверждении членства. Утверждающий членство будет одним из пользователей в группе администраторов. Ниже приводится грубая схема, которую я имею в виду. Я новичок в моделировании баз данных и хотел бы получить некоторые отзывы о следующей реализации. В частности, я не уверен, должна ли таблица членства иметь столбец «Approve_by» с использованием FK «user_id», или мне следует создать отдельную таблицу для поддержания MembershipStatus (id, members_id, status ,mitted_by) ?? Я предполагаю, что наличие отдельной таблицы MembershipStatus более уместно здесь, но не уверен в этом. Также я планирую использовать ActiveRecord в качестве ORM в этом приложении. Я ценю любые комментарии или предложения по реализации этого проекта / схемы.

User:
  id, Primary Key
  userid, Integer, Unique
  username, String, Unique
  email, String, Unique
  created_at, DateTime
  updated_at, DateTime

Group:
  id, Primary Key
  groupid, Integer, Unique
  groupname, String, Unique
  created_at, DateTime
  updated_at, DateTime

Membership:
  PK(user_id, group_id)
  status, String
  approved_by, user_id FK to User table 
  created_at, DateTime
  updated_at, DateTime

MembershipStatus 
  id
  membership_id FK to Membership table
  status, String
  approved_by, user_id FK to User table 
  created_at, DateTime
  updated_at, DateTime

-Спасибо

Answer 1

выглядит довольно хорошо.

Вы показываете Appro_by в 2 таблицах. Если вы сохраняете таблицу MembershipStatus, то это то место, которое должно принадлежать. Кроме того, название «Verified_by» подразумевает статус «утвержден», который может существовать или не существовать. вы можете подумать о другом имени ...

у вас также должна быть таблица, в которой, вероятно, указано, какие пользователи являются администраторами для каких групп. таким образом, вы можете закодировать защиту на стороне базы данных для тех, кому разрешено утверждать, а также хранить, кто на самом деле одобрил.

также я не большой поклонник хранения истории аудита в таблице, как вы показываете. Либо используйте базу данных, встроенную в аудит, либо извлеките ее в другую таблицу для записи истории аудита.

наконец, id и идентификатор пользователя кажутся избыточными. перейти с идентификатором пользователя. (аналогично другим таблицам)