如果您正在構建eshop或任何其他使用會話在請求之間存儲數據的應用程序，則無關緊要。 如果您不想讓用戶註冊，您需要允許他在匿名的情況下執行某些任務（如果可能，用戶必須有註冊理由）。如何在登錄後合併用戶數據？
出現了一個問題 - 如果用戶決定使用他的現有個人資料登錄，他可能已在他的「匿名」會話中擁有一些數據。
合併這些數據的最佳做法是什麼？我猜應用程序應儘可能自動合併它，或讓用戶決定不可能的地方。
但是我問的更多的是，是否有任何有關如何有效地執行數據庫中魔術（通常存儲會話數據）的資源。
我在我的腦海兩個基本方案：
我們可以說第一個解決方案可能會更有效，因爲關於任何關係的信息可能意味着比關於用戶的數據更少的數據。但是在閱讀數據時，這也意味着更多的努力（因爲我們首先需要閱讀關係以獲得實際的用戶數據）。
是否有任何文章/資源爲此特定用例設計數據結構（匿名+用戶數據）？
出色的問題，使用用戶數據的任何應用程序開發人員應該問了，可悲的是極少數做:(
其實，這裏有兩個完全獨立的問題：
Q1 - 在什麼階段需要用戶登錄/向上
Q2 - ？數據併發性和衝突解決（見下文）
這裏對每個問題進行一些分析。請原諒我自己的「沮喪的用戶」體驗帶來的額外激情。 :)
Q1是一個純粹的可用性問題。答案其實很明顯：
即使需要保存狀態也不是一個理由本身。如果我是用戶不想保存該狀態，那麼不要強迫我簽字！請！ （作爲用戶）想要保存我的數據以備將來使用。在這裏，我說作爲用戶浪費時間簽署，只發現該網站沒用。如果你想擺脫太多的用戶，那是正確的方法。在任何其他情況下 - 請儘可能延遲！
爲什麼這麼多網站完全無視這樣一個明顯的規則？我可以看到的可能原因：
R1-開發人員友好vs用戶友好。是的，開發人員需要馬上登錄，所以我們不需要打擾併發（Q2）。所以我們可以節省開發人員的成本，時間等。在這種情況下稱爲用戶體驗。這不一定是你想要尋找節約的地方。特別是，因爲解決方案不應該那麼難（見下文）。
R2 - 作出決定的設計師或經理是一位「室內愛好者」:)她生活在快樂的生活中，擁有超高速互聯網連接的超高速計算機，無法想象唱歌對於任何人來說都很難用戶。那爲什麼這麼重要？原因如下：
它打破了應用程序流程。生活在上個世紀的網站仍然以有時相當冗長的形式取代整個屏幕。有些形式設計得不好，有些形式不規則，有些根本不起作用。有些提交按鈕由於某種原因在瀏覽器中被禁用。有些表單設計師有天才的想法，可以鎖定某些沒有明顯變化或顏色的領域。那麼如果你不想讓我填充它，那就不要讓我看看這個領域！
如果網站認真對待用戶的數據，它必須要求電子郵件並且必須驗證它！爲什麼？我還能回到忘記所有其他憑證的用戶身上嗎？爲什麼驗證？如果用戶錯誤輸入了電子郵件會怎麼樣？如果我不驗證它，下次用戶嘗試使用正確的電子郵件恢復密碼時，恢復將失敗，並且所有數據都將丟失！很明顯，但仍然有網站沒有這樣做。然後，我需要等到收到驗證電子郵件後點擊，希望能夠在瀏覽器中打開格式良好並且唯一可識別的鏈接，並且由於編碼檢測功能損壞而無法使用某些有趣的字符，從而導致整個鏈接無法使用。
互聯網連接速度可能會變慢或中斷，每增加一步都會導致一連串的痛苦。即使有良好的連接，它也會在這裏和那裏發生，頁面突然加載需要更長的時間。此外，電子郵件可能無法立即到達。然後不耐煩的用戶開始瘋狂地點擊「重新發送驗證」鏈接。在這種情況下，90％的網站使用新的令牌重新發送鏈接，但也禁用所有先前的令牌。然後，幾封電子郵件以不可預測的順序到達，而窮人用戶必須妄加猜測，哪一個（並且只有一個）仍然有效。現在爲什麼這些網站很難保持幾個令牌活躍，就這個情況而言，這是我的理解。
最後還是有這麼難以忽略的習慣，網站堅持所謂的「用戶名」。所以現在，在我的電子郵件旁邊，我不得不想出這個獨特的用戶名，與以前的任何用戶不同！非常感謝你讓它變得甜美和輕鬆！我自己的處理方式是使用我的電子郵件作爲用戶名。可悲的是，仍然有網站不接受它！那麼如果一些有趣的類型使用我的電子郵件作爲他的用戶名？如果您的電子郵件地址爲[email protected]，則不是那麼不切實際。但爲什麼不使用電子郵件和密碼來避免所有這些混亂？
這裏是一些可能的指導方針，以減輕使用者的痛苦：
只有逼我登錄/，如果你確實需要，給我一個機會，不要選擇！
使它成爲一個頁面的形式，所以我知道我在做什麼，不用說，使用盡可能少的輸入字段。理想情況下只有電子郵件和密碼（可能兩次），沒有用戶名！
將您的登錄窗口顯示爲頁面頂部的小窗口，無需重新加載，只需單擊鼠標即可將其從窗口中刪除。不要強迫我去尋找「關閉」按鈕，更糟糕的是，我可能會混淆其他東西的圖標！
帳號供用戶點擊來回/重新加載按鈕。重新加載時不要清除表單！根本不要放清楚的按鈕！偶然點擊太容易。您要求我填寫的數據首先不應太長，以至於無需「幫助」即可清除，我無法重新輸入。
現在質疑Q2。在這裏，我們知道任何時候需要合併兩個數據的衝突解決問題。例如，匿名數據和註冊用戶數據，而且每當兩個用戶修改相同的數據，或者同一用戶在不同時間從不同設備修改它，或者本地存儲的數據與服務器數據衝突等等。
但無論來源是什麼，問題總是相同的。我們有兩個數據，比如說兩個對象$ obj1和$ obj2，你需要產生你的單個合併對象$ obj3。邏輯可以像服務器的對象總是贏的規則一樣簡單，或者最後修改的對象總是贏，或者最後修改的對象鍵總是贏或者更復雜的邏輯。這真的取決於你的應用程序的性質。但是，在每種情況下，只需要使用返回$ obj3的參數$ obj1，$ obj2來編寫邏輯函數。
，這將有可能在許多情況下，工作的解決方案是存儲在每個對象的屬性（鍵）時間戳，讓在同步的時刻最新的改變關鍵的勝利。例如，針對同一用戶在不同設備匿名時修改不同屬性的情況。假設我昨天在設備AA上修改了密鑰A和B，然後今天從設備BB登錄，進入另一個B並將其保存到服務器，然後切換回我的匿名設備AA進入另一個A沒有從昨天改變舊的B，然後意識到我想登錄並同步。那麼我的本地B顯然很老，並且顯然不應該覆蓋最近在設備BB上更改的B的值。在這個看似複雜的案例中，上述解決方案可以無縫有效地工作。相反，只將時間戳放在整個對象上是錯誤的。
現在，在某些情況下，它可能是有意義的保持兩個對象，並且，如通過添加額外的屬性來區分它們，比如在Radek的問題中提出的情況1。例如，Dropbox在文件末尾添加了「用戶X的衝突副本」之類的內容。就像在Dropbox案例中一樣，這對於協作應用程序來說是明智的，用戶喜歡有一些版本控制。 但是，在這些情況下，您作爲開發人員只需保存兩份副本，並讓用戶處理該問題。
如果在另一方面，你必須寫一個基於用戶的數據的複雜邏輯，其遊逛可以是一個噩夢兩個不同的副本。在那種情況下，我會將數據分成兩組（例如，創建兩個對象）。第一組具有代表整個應用程序狀態的數據，這非常重要。對於那些數據，我會使用上面的衝突解決方案或類似的方法。然後第二組是用戶特定的，我將這兩個數據作爲兩個單獨的條目存儲在數據庫中，正確標記它們（像Dropbox那樣），然後讓用戶處理他們項目中兩個（或更多）條目的列表。最後，如果數據庫管理的額外複雜因素使開發人員感到不安，並且由於Radek要求提供資源參考，我想通過提及博客條目StackMob offline Sync來「殺死兩隻蒼蠅」，其解決方案同時提供了兩種方法數據庫和用戶管理功能，從而減輕開發人員的痛苦。在搜索數據一致性，衝突解決方法等時，肯定會發現更多信息。最後，我必須補充強制性聲明，這裏寫的所有內容都只是我自己的想法和建議，每個人都應該承擔自己的風險，並且不要求我承擔責任，如果你突然得到太多快樂的用戶你的系統崩潰:)
由於我自己工作的一個應用程序，在這裏我實現所有這些方面，我當然聽到其他人的意見，並還有什麼人有關於這個問題說的很感興趣。
根據我的經驗 - 無論是作爲需要登錄的網站的用戶，還是作爲登錄用戶的開發人員 - 我都不認爲我曾經見過一個網站的行爲如此。
常見模式是讓用戶匿名，當他們第一次做某些事情需要保存狀態時，系統會提示他們登錄。然後記住以前的操作並且用戶可以繼續。例如，如果他們嘗試向購物車中添加商品，系統會提示他們登錄，然後在登錄後將商品放入購物車中。
我想有些地方可以讓你裝滿購物車，然後登錄購物車與具體用戶關聯。
我會創建具有用於檢索其他的東西，如姓名，地址等
隨着匿名用戶，我會創造SessionUser的現場互動的狀態和一個域名爲用戶ID一個SessionUser對象具有UserId的空引用的對象。這意味着我們無法解析名稱或地址，但我們仍然可以保存狀態。他們正在執行的操作，他們正在查看的頁面等。
一旦他們登錄，我們不必合併兩個對象，我們只需在SessionUser中填充UserId字段，現在我們可以遍歷對象圖來獲取姓名，電子郵件地址或其他地址。
去亞馬遜，登錄，把東西放在籃子裏，打開另一個瀏覽器，並把其他東西。現在去結帳。 – Gonfva