將信息存儲在未註冊的客戶用戶

Question

一個已經暴露出來的問題是向未註冊的用戶開放我們的應用程序（我們可以將其看作有點像在線商店）。

目前，有一個管理系統，員工由超級用戶和一個網站與客戶通過註冊添加自己添加。

我們被要求允許客戶在不註冊或登錄的情況下使用網站，但我們不想破壞'訂單'表 - 我們仍然需要分別引用每個客戶並維護註冊用戶的功能（地址查詢，購買歷史等）。我們一直在思考的主要想法是使用未註冊的客戶的電子郵件地址替代客戶表中的代理鍵（或散列表），以便新老客戶只需在結帳時輸入其電子郵件地址即可被添加到我們的數據庫並收到他們的訂單確認。每個客戶的不同電子郵件地址的問題可以通過管理端的「合併」工具得到緩解，而多個客戶共享相同電子郵件（某些辦公環境）的問題對我們來說並不是什麼大問題。

主要問題是：真實世界的應用程序如何處理未註冊的用戶？

更新響應答案

我們不想強迫註冊用戶每即使他們的電子郵件地址已經是我們的註冊用戶系統上的時間登錄。另外，如果人們主張使用電子郵件地址作爲關鍵字，那麼您將如何處理註冊帳戶持有者將其電子郵件地址放棄給其他人的情形？

Answer 1

在我們公司，我們這樣來做：

當任何用戶作出命令
1. ，我們來看看他的電子郵件（他是需要指定而且是唯一）的customers表。
2. 如果不存在，我們只需創建用戶（我們已經擁有用戶訂單中的所有必需數據），並將其標記爲registred=0。
3. 現在我們用他的用戶ID繼續訂單流程。
4. 當有人在該郵件下注冊時，我們只需更新其憑據（無論他指定），同時保留其訂單歷史記錄和其他任何內容。我不認爲這是一個安全問題，用戶需要確認電子郵件地址，所以除非該帳戶真的是他的，否則他不會註冊。

我們不允許已經registred電子郵件創建訂單，所以應該清除掉你的郵件合併，因爲沒有人將能夠創建一個註冊和未註冊帳戶下一個電子郵件地址，當他做了，他將永遠無法再購物未註冊。希望這可以幫助。

Answer 2

我建議不要在這種情況下使用自然鍵，因爲他們對註冊不感興趣，並且不希望他們的細節被記住（至少這是我在未註冊模式下的想法）。

使用一個完全合成的鍵（就像一個計數器），然後就這樣。

Answer 3

與Pal不同，我非常喜歡使用自然數據作爲關鍵。

使用未註冊的客戶的電子郵件地址作爲代理鍵

首先，這種說法是一種矛盾的說法。根據定義，代理鍵與實際數據無關。

接下來，如果你有他們的電子郵件地址，這意味着他們已經完成某種註冊過程。

如果你有用戶共享一個電子郵件地址（即身份斷言），那麼根據定義，他們想分享這個身份 - 試圖區分他們不是你的問題 - 特別是你已經提供了一個機制可以單獨識別。

你要擔心的是是否在沒有其他身份驗證使用的電子郵件地址，你正在泄漏，否則是保密的（例如，以前的訂單）信息