database - 登录后如何合并用户数据？

Question

无论您是要构建eshop还是使用 session 在请求之间存储一些数据的任何其他应用程序。
如果您不想通过要求用户注册来惹恼用户，则需要允许他在可能的情况下匿名执行某些任务(用户确实必须有注册理由)。

出现了一个问题-如果用户决定使用其现有个人资料登录，则他的“匿名” session 中可能已经有一些数据。

合并这些数据的最佳实践是什么？我猜该应用程序应该在可能的地方自动合并它，或者让用户决定在不可能的地方。

但是我要问的是，是否有任何资源可以有效地解决数据库(通常存储 session 数据)中的问题。

我有两个基本解决方案:

要保留匿名 session 数据并仅添加另一个“关系”，说明在合并位置和方式中实际使用的内容

物理合并这些数据

我们可以说第一种解决方案可能会更有效，因为有关任何关系的信息可能意味着比有关用户的数据少的数据。但这也意味着读取数据时需要付出更多的努力(因为我们首先需要读取关系才能获取实际的用户数据)。

是否有任何文章/资源用于 设计此特定用例(匿名+用户数据)的数据结构？

Answer 1

任何使用用户数据的应用程序开发人员都应该问一个非常好的问题，可惜的是，很少有人这样做:(

实际上，这里有两个完全独立的问题:

问题1-在什么阶段要求用户登录/注册？

Q2-数据并发和冲突解决(请参见下文)。

这里是对每个问题的一些分析。请原谅我来自“沮丧的用户”体验的额外热情。 :)

Q1是一个纯粹的可用性问题。答案实际上是显而易见的:

避免或延迟强制用户登录!

仅仅需要保存状态本身还不够。如果我作为用户不希望保存该状态，请不要强迫我签名!请!

您(作为网站)证明强迫我签名的唯一理由是当我(作为用户)要保存数据供以后使用时。在这里，我说的是用户浪费时间在签名上，只是发现该站点无用。如果您想摆脱太多的用户，那是正确的方法。在任何其他情况下-请尽量延迟!

为什么这么多站点完全不理会这种明显的规则？我看到的可能原因:

R1-开发人员友好vs用户友好。是的，要求开发者立即登录对开发人员很友好，因此我们无需为并发(Q2)操心。这样我们可以节省开发人员的成本，时间等。但是每次节省都是有代价的!在这种情况下，这称为用户体验。您不一定要在哪里寻找保存位置。特别是，由于解决方案不那么困难(请参阅下文)。

R2-做出此决定的设计师或经理是“室内爱好者” :)她过着幸福的生活，周围环绕着具有超高速互联网连接的超高速计算机，无法想象唱歌对任何用户而言都很难。那为什么这么大呢？这么多原因:

中断应用程序流程。居住在上个世纪的网站仍然以有时相当长的形式代替了整个屏幕。有些表格设计不当，有些指令不稳定，有些根本不起作用。有些具有提交按钮，由于某些原因，该按钮在使用的浏览器中被禁用。
一些表单设计者有一个天才的想法，即锁定几乎没有明显变化或颜色的某些字段。如果您不希望我填写此字段，请不要显示给我!

如果该站点重视用户数据，则必须请求电子邮件并必须对其进行验证!为什么？我还应该如何找回忘记所有其他凭据的用户？为什么要验证？如果用户输入了错误的电子邮件怎么办？如果我不验证该密码，则下次用户尝试使用正确的电子邮件恢复密码时，恢复将失败并且所有数据都将丢失!显而易见，但是仍然有一些网站没有这样做。然后，我需要等到收到验证电子邮件后，再单击，单击该格式正确且可唯一标识的链接，该链接不会在我的浏览器中中断，也不会由于编码检测中断而得到一些有趣的字符，从而使整个链接无法使用。

互联网连接速度可能很慢或中断，这使每个附加步骤都变得很痛苦。即使连接良好，它也会在这里到那里突然加载更长的时间。此外，电子邮件可能不会立即到达。然后，急躁的用户开始疯狂地单击“重新发送验证”链接。在这种情况下，90％的站点会使用新 token 重新发送其链接，但还会禁用所有以前的 token 。然后，几封电子邮件以无法预测的顺序到达，可怜的用户不得不徒劳地猜测，哪一封(仍然只有一封)仍然有效。现在，对于这种情况，为什么这些站点很难保持多个 token 处于 Activity 状态，这超出了我的理解。

最后，对于站点来说，坚持所谓的“用户名”仍然是一种难以理解的习惯。因此，现在，除了我的电子邮件外，我还必须努力想出这个唯一的用户名，该用户名不同于以前的任何用户!非常感谢您使它变得甜美轻松!我自己的处理方式是使用我的电子邮件作为用户名。可悲的是，仍然有一些网站不接受它!那如果某种有趣的类型使用我的电子邮件作为他的用户名怎么办？如果您的电子邮件是bill@gates.com，这并非不切实际。但是，为什么不使用电子邮件和密码来避免这些麻烦呢？

这里有一些减轻用户痛苦的准则:

如果您绝对需要，请强迫我登录/注册，让我有机会选择不注册!

使其成为一个页面表单，所以我知道我在做什么，并且不用说，使用尽可能少的输入字段。理想情况下，只有电子邮件和密码(可能是两次)，没有用户名!

将您的登录表单显示为页面顶部的小窗口，而无需重新加载，并且只需单击一下即可离开该窗口，让我摆脱它。不要强迫我寻找“关闭”按钮，或者更糟糕的是，我可能会为其他事情感到困惑!

用户单击“后退/前进”并重新加载按钮的帐户。重新加载时不要清除表格!根本不要放置清除按钮!意外单击太容易了。您要求我填写的数据不应放在首位，以至于我无需“协助”清除就无法重新输入数据。

现在问问题2。在这里，我们有一个众所周知的解决冲突的问题，该问题在任何两个数据需要合并时都会发生。例如，匿名数据和注册用户数据，也包括两个用户修改相同数据，或者同一用户在不同时间从不同设备修改数据，或者本地存储的数据与服务器数据发生冲突等的情况。

但是，无论出处是什么，问题总是相同的。我们有两个数据，例如两个对象$ 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来“一 Gunicorn 死两只苍蝇”，其解决方案同时提供数据库和用户管理功能，从而减轻了开发人员的痛苦。当搜索数据并发，冲突解决之类的东西时，肯定会有很多信息可以找到。

最后，我必须添加强制性的免责声明，此处写的所有内容仅是我自己的想法和建议，如果您突然有太多高兴的用户使系统崩溃，则每个人都应自担风险，不要对我负责: )

当我自己在一个应用程序中工作时(我正在实现所有这些方面)，我当然非常有兴趣听到其他意见以及其他人们对此主题的看法。