Php 用户测试/组测试的体系结构

我有一个用户可以执行测试的用例。这是基于邀请。因此管理员可以向用户发送邀请以执行选定的测试。还可以创建一个由多个用户组成的团队，并向团队的所有用户发送邀请，以便为该团队执行测试

有几种方法可以创建这些模型，但我不确定什么是最好的方法（或者甚至还有其他方法）

选项1

• 用户：id，name
• 团队：id，姓名
• UserTeam:user\u id，team\u id
• UserInvite:id，user\u id
• TeamInvite:id，team\u id
• 测试：id，用户id，用户邀请id（可以为空），团队邀请id（可以为空），键入[user | team]

选项2

• 用户：id，name
• 团队：id，姓名
• UserTeam:user\u id，team\u id
• 邀请：id，用户id（可以为空），团队id（可以为空），键入[用户|团队]
• 测试：id、用户id、邀请id

---

所以最好是单独邀请（针对团队和用户）并将测试链接到团队邀请或用户邀请（如选项1）。或者另一种选择：只邀请一次，然后确定它是否链接到团队或用户（如选项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

---

您还可以将

团队

定义为特殊的

用户

，其中

Team.id

既是

主键

又是

外键

到

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`))

---

我喜欢您的第三个选项，因为它进一步抽象了模型。我需要测试最常用查询的附加连接的性能影响：团队中的用户是否没有完成来自invite X的测试？根据邀请的时间戳（而不是测试），您的最新测试结果是什么。如果性能可以忽略不计，我会选择选项3。否则我将坚持第二条，我认为，选择这条作为最终答案，因为有了ypercube的建议，团队就不能没有伴随的用户而存在。我们的用户和团队数据库表在多个地方使用，这将导致完整的代码重构。谢谢你们两位的帮助。你们说一个团队有可能拥有一个主键，同时也是用户主键的外键？我从来没有使用过这个想法，但是如果你说这可以将邀请链接到同一个团队/用户，那么这可能是一个理想的情况。我不确定这在MySql中是否有效，但我需要对此进行测试。