混合多對一的層次結構

我有一個收集和處理用戶信息的應用程序。混合多對一的層次結構

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

的工作流程是：
進程外的註冊信息，
- 如果該電子郵件是新加的，否則它分配。
- 如果這個人是新的添加它，否則分配它。

例代碼：

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

}

的代碼只是示例，在實際的實現中有更多的觸發器和依賴關係，以及處理該事件的順序：
登記 - >電子郵件 - >人

這顯然不是一種方便的方式來更新正義創造力特德元素...我正在尋找e-disign-patern或DB架構如何優化這種情況。

編輯：
可能有多重登記一個電子郵件，可能有多個電子郵件到一個人。

來源

2013-07-17 d.raev

'旁註：'你錯過了將'person_id'標記爲'parson_id' – DevZer0

你能否提供這些表之間的關係？對我來說，似乎你最好把所有東西都合併到一張表中，除非有一對一的關係。由於您使用的是PHP，因此您並不需要「更新剛剛創建的元素」，只需在獲取所有必填信息來填充數據庫時創建它們即可。 – Eggplant

我會建議，而不是檢查記錄存在，你只需使用ON DUPLICATE KEY UPDATE語法插入一個新的記錄。使用它可以觸發它返回新記錄的ID或現有記錄的ID（如果找到）。 – Kickstart

我很難理解爲什麼使用系統中存在的名稱而不同的電子郵件進行註冊嘗試會導致將不同的電子郵件與現有用戶關聯起來。通常在這樣的系統中，電子郵件被視爲唯一的ID，並且新用戶被迫選擇不存在的用戶名。此外，如果這是一種典型的交互式註冊，則很可能不需要將註冊嘗試存儲在單獨的表格中。如果您確實希望用戶與多個郵件相關聯，則更好的方法可能是將初始註冊電子郵件作爲主要電子郵件，並允許登錄用戶向其帳戶添加輔助電子郵件。

來源

2013-07-17 09:23:03

好點。註冊不用於登錄，它只是從這個應用程序處理的數據（它來自不同的來源） –

很難幫助系統設計，而不瞭解該用戶註冊處理的目的和優先結果。有一件事情對我來說似乎很明顯，可能會簡化一些事情，那就是註冊表中的email_id。我認爲這是多餘的，可能會違反系統中單點籤條的規則。其他的事情是我會考慮註冊作爲輸入和數據保存在個人和電子郵件作爲處理結果。這樣，系統的所有後續處理和當前狀態僅由這兩個表格表示。心連心 –

混合多對一的層次結構

回答

相關問題