反转多对一层次结构


Reverce many to one hierarchy

我有一个收集和处理用户信息的应用程序。

CREATE TABLE registrations(
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50),
    email VARCHAR(50),
    email_id INT
);
CREATE TABLE email(
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    email VARCHAR(50),
    person_id INT
);
CREATE TABLE person(
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(50)
);
ALTER TABLE registrations 
   ADD FOREIGN KEY (email_id) REFERENCES email (id);
ALTER TABLE email 
   ADD FOREIGN KEY (person_id) REFERENCES person (id);

小提琴

工作流程为:
-处理注册信息,
-如果电子邮件是新的,则添加它,否则分配它。
-如果这个人是新来的,添加它,否则分配它。

示例代码:

function newRegistration($input){
   $registraton = new Registration();
   $registraton->setUsername($input['username']);
   $registraton->save();
   $email = null;  
   if(Email::exists($input['email'])){
       $email = Email::find($input['email']);
   }else{
       $email = Email::create($input['email']);
   }
   $registraton->setEmailId($email->getId());
   $registraton->save();//!!
   $person = null
   if(Person::exists($input['name'])){
       $person = Person::find($input['name']);
   }else{
       $person = Person::create($input['name']);
   }
   if(!$email->getPersonId()){
       $email->setPersonId($person->getId());
       $email->save();//!!
   }

}

代码只是一个例子,在实际实现中有更多的触发器和依赖项,以及处理事件的顺序:
注册->电子邮件->人员

这显然不是更新刚刚创建的元素的方便方式。。。我正在寻找如何优化这个场景的设计模式或DB架构。

编辑
可能存在与一个电子邮件的多次注册,可能有多封电子邮件发送给一个人。

我很难理解为什么使用系统中存在但不同电子邮件的名称进行注册会导致将不同的电子邮件与现有用户关联。通常在这样的系统中,电子邮件被视为唯一的ID,新用户被迫选择不存在的用户名。此外,如果这是典型的交互式注册,则很可能不需要将注册尝试存储在单独的表中。如果你真的希望用户与多封邮件关联,更好的方法可能是将初始注册电子邮件视为主要电子邮件,并允许loggedin用户将次要电子邮件添加到他们的帐户中。