我不太清楚如何處理這個問題：數據庫模式設計：如何處理未經驗證的邀請？
我正在創建一個只有邀請註冊系統的Web應用程序。管理員用戶向用戶發送電子郵件邀請，用戶點擊該鏈接，並將他們帶到可以創建已鏈接到其電子郵件地址的帳戶的頁面。
我最初的想法是在我的users表中插入一行，verified列標記爲false。問題是我有用戶名和密碼作爲必填字段和用戶名必須是唯一的。所以我不能只是插入一個空行來填寫。
我應該爲邀請創建一個單獨的表嗎？處理這種情況的最佳方法是什麼？
更新：管理將進入第一個名字，姓氏，電子郵件地址和用戶角色（權限）。所以我需要將所有這些東西存儲在邀請表中。如果電子郵件需要重新發送，我還可以存儲發送的日期並更新該值。
是的，你會製作一個單獨的表來管理邀請。
然後當邀請被接受時，你有幾個選擇。首先，您需要決定是否需要維護與原始邀請的關聯，以便追蹤或「家譜」或其他歷史用途。
接下來，如果是這樣，您需要決定如何做到這一點。刪除邀請並存儲任何與用戶記錄相關的信息？保留邀請記錄並設置外鍵？
如果我更瞭解您打算創建的系統，我可能會提供一些更加精細的建議。
您必須考慮請求丟失，意外刪除或因其他原因而無法使用且必須重新發送的情況。
此外，邀請是與註冊不同的實體。我認爲你應該創建一個單獨的表來跟蹤邀請與看看誰註冊（從哪個邀請）
感謝您的回答。我沒有想過丟失/刪除的邀請電子郵件，直到你的答案。 – Andrew 2009-10-27 20:08:37
幾種方法來看這個。如果您在創建另一個表格的單獨路線中評估階段結束時發生了什麼，您是否必須將這些評估用戶複製到您的真實用戶表格中？用戶名可以默認爲一個特製的GUID，您已編程設置該GUID以處理進入用戶表的操作。
我會推薦一張單獨的表格用於邀請。我很清楚，你的邀請基本上是允許某人註冊的標誌。
令牌，確切地說！除非他們的電子郵件地址（代幣）已被添加到列表 – Andrew 2009-10-27 18:29:42
.hmm，否則根據您最近的更新，我想我的意見已經改變，否則用戶無法註冊。之前，尚不清楚發送邀請時是否指定了很多帳戶信息。 如果管理員已經知道他們的名字，電子郵件，他們的角色等，那麼你可能只是創建用戶並返回到你的「已驗證」列的想法。您始終可以使用他們的電子郵件地址作爲他們的用戶名，您可以在驗證/完成註冊後允許他們更改。 – HackedByChinese 2009-10-27 18:34:10
單獨的表格對我來說最有意義。這將允許您在用戶表中維護數據完整性，並提供更易讀的數據模型。說「邀請進入邀請表」比說「邀請進入用戶表，但驗證列設置爲假」更容易。
我添加了對我的問題的更新。如果您有更具體的問題，請詢問。 – Andrew 2009-10-27 18:27:01
是的，我真的沒有什麼補充。您只需要問自己，在邀請 - 註冊過程之後，您所關注的歷史信息應如何保留。 – 2009-10-27 19:03:36
謝謝，我沒有想到如何處理歷史，直到你的答案。 – Andrew 2009-10-27 20:06:59