Архитектура для пользовательских тестов / групповых тестов

Question

У меня есть случай, когда пользователь может выполнить тест.Это основано на приглашении.Таким образом, администратор может отправить приглашение пользователю для выполнения выбранного теста.Можно также создать группу из нескольких пользователей и отправить всем пользователям группы приглашение для выполнения теста для этой команды.

Существует несколько вариантов создания этих моделей, но я не уверенчто является лучшим способом (или, возможно, есть даже альтернатива).

Вариант 1

• Пользователь: идентификатор, имя
• Команда: id, имя
• UserTeam: user_id, team_id
• UserInvite: id, user_id
• TeamInvite: id, team_id
• Тест: id, user_id, user_invite_id(может быть нулевым), team_invite_id (может быть нулевым), введите [user | team]

Option 2

• Пользователь: id, имя
• Команда: id, имя
• UserTeam: user_id, team_id
• Пригласить: id, user_id (может быть нулевым), team_id (может быть нулевым), ввести [user |team]
• Test: id, user_id, Invite_id

Так что лучше иметь отдельные приглашения (для команд и пользователей) и связать тесты с приглашением команды или пользователем-инвитировать Опция 1).Или альтернатива: иметь одно приглашение и определить, связано ли оно с командой или пользователем (как вариант 2)?

Answer 1

Вы также можете иметь Team, определенный как специальный User, где Team.id является одновременно Primary Key и Foreign Key до User.id.Тогда ваши таблицы будут выглядеть так:

Option 3

    * User: id, name                    --- User data
    * Team: id, name                    --- Team data (name field can be dropped)
    * UserTeam: user_id, team_id        --- User belongs to Team
    * Test: id, description             --- Test definition
    * Invite: id, user_id, test_id      --- Invitation for User to make Test
    * TestDone: id, user_id, invite_id  --- TestDone after User accepted Invitation

Так что все команды тоже будут пользователями.

Я немного изменил тест-приглашение после повторного прочтения вашего описания, касающегося этой части.

---

Пример сценария:

CREATE TABLE user
( id int NOT NULL AUTO_INCREMENT
, name VARCHAR(20) NOT NULL
, PRIMARY KEY (id)
) ;

CREATE TABLE team
( id int NOT NULL
, teamname VARCHAR(20) NOT NULL
, CONSTRAINT PK_team_id
    PRIMARY KEY (id)
, CONSTRAINT FK_team_id_TO_user_id
    FOREIGN KEY (id)
      REFERENCES user(id)
) ;

INSERT INTO user
VALUES
  (1, 'John')
, (2, 'George')
, (3, 'Mary' )
, (4, 'Team-1')  ;

SELECT * FROM user ;

| id | name   |
| 1  | John   |
| 2  | George | 
| 3  | Mary   |    
| 4  | Team-1 |       

INSERT INTO team
VALUES
 (4, 'Team-One') ;

SELECT * FROM team ;

| id | teamname |  
| 4  | Team-One | 

INSERT INTO team
VALUES
 (5, 'Team-Two') ;

> Cannot add or update a child row: a foreign key constraint fails
> (`test/team`, CONSTRAINT `FK_team_id_TO_user_id` FOREIGN KEY (`id`)
> REFERENCES `user` (`id`))

Answer 2

Лично я бы выбрал ваш второй вариант.

Однако, возможно, вы захотите изучить и третий вариант.Это позволяет хранить приглашения, отправленные нескольким командам и пользователям:

user: id, name
team: id, name
invite: id
test: id, invite_id
user_invite: invite_id, user_id
team_invite: invite_id, team_id