많은 계층 구조를 되 돌린다

Question

나는 사용자 정보를 수집하고 처리하는 앱을 가지고있다.

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

fiddle

워크 플로는

:
등록 정보 - 프로세스,
이메일 -if는 할당 다른, 추가의 새로운 기능입니다.
- 사람이 새로 추가 된 경우 추가하거나 추가하십시오.

예 코드 :

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();//!! 
    } 

}

, 실제 구현에 더 트리거와 의존성 그냥 예가되는 코드 및 처리 사건의 순서 :
등록 -> 이메일 -> 사람

이것은 분명히 그냥 crea를 업데이 트하는 편리한 방법이 아닙니다 테드 요소 ... 나는이 시나리오를 최적화하는 방법을 disign-patern 또는 DB 아키텍처를 찾고 있습니다.

편집 :
한 이메일과 곱셈 등록이있을 수는 한 사람에 여러 개의 이메일이있을 수 있습니다.

Answer 1

시스템에 있지만 다른 전자 메일 이름으로 등록 시도가 다른 전자 메일을 기존 사용자와 연결해야하는 이유를 이해하는 데 어려움이 있습니다. 일반적으로 시스템에서 전자 메일은 고유 한 ID로 취급되며 새 사용자는 존재하지 않는 사용자 이름을 선택해야합니다. 또한 이것이 전형적인 대화 형 등록 인 경우 등록 시도를 별도의 테이블에 저장할 필요가 거의 없습니다. 사용자가 둘 이상의 메일과 연결되기를 원한다면 초기 등록 이메일을 기본 이메일로 취급하고 로그인 한 사용자가 자신의 계정에 보조 이메일을 추가 할 수 있도록하는 것이 좋습니다.