有哪些方法可以在数据库中存储有关匿名/来宾用户的信息？

Question

我们的应用程序有一个在线商店和其他功能，通常要求用户在完成销售前注册，在此过程中创建一个独特的customer_ID。当他们返回时，他们可以登录并从数据库中检索他们的联系方式和交易历史记录。

我们正在探索在“匿名”或“客户”客户的情况下该做什么，向不想注册的客户开放在线商店，以及在后端应用程序中登录的销售情况接收客户的电子邮件，邮政地址等太费时间了。该解决方案也在网上商店之外提供应用程序。

多家公司使用相同的数据库，数据库建立在party model结构上，因此我们研究了几个选项：

1. 将所有匿名客户存储在customer_ID表格中的一个预定义transaction下：
   每个匿名用户都有
   1. customer_ID = 0，每个真实用户都有customer_ID > 0
      • 这是直接硬编码到应用程序中
      • 但更多参与确定哪些客户属于哪家公司
      • customer_ID = 0的详细信息是否存在于数据库的customer表中或作为应用程序中的对象？
        • 如果在数据库中，可以进行哪些数据库级约束以确保它始终存在？
        • 如果不在数据库中，则从transaction.customer_ID到customer.customer_ID的外键约束不再起作用
   2. customer_ID与公司party_ID相同
      • 更容易确定每家公司的总销售额等
      • 这会使事情变得混乱，因为公司似乎是自己的客户，而不是其他独特的客户
2. 为每位新匿名客户（每个会话）生成一个唯一的customer_ID
   • 如果同一物理用户返回怎么办？将有许多记录重复相同类型的数据;电子邮件，送货地址等。
3. 使用其他唯一密钥（例如电子邮件地址）来引用客户
   • 并非总是可靠，因为人们有时会使用多个电子邮件地址，或留下旧地址。
   • 如果没有电子邮件地址，如车间，备考发票等情况怎么办？
4. 其他一些Stack Overflow启发式解决方案！

加成

在其他地方建议使用＃2和＃3的组合 - 尝试为每个客户存储单个记录，如果可能，使用电子邮件地址存储，或者如果没有，则在每次访问时记录新记录。

我应该指出，我们不需要为每个匿名客户存储记录，但似乎关系数据库是为了处理关系而构建的，所以有一个NULL或者customer_ID表中transaction没有引用实际客户记录似乎是错误的......

我还必须强调，这个问题的目的是确定哪些现实世界的解决方案可以记录“休闲”交易，其中没有给出邮政地址或电子邮件地址（想象一个超市chekout）以及在线商店交易无论是否存储，都会给出电子邮件地址和邮政地址。

SO社区过去使用了哪些解决方案？

Answer 1

假设您需要所有在线订单的电子邮件地址，您可以在每个订单未完成登录时为每个客户创建一个临时帐户。

这可以通过使用结账时提供的送货地址和其他信息来填写帐户，并通过电子邮件发送随机临时密码（可选择将其标记为需要更改首次登录，如果是功能内置于网站中）。这需要他们尽最大努力来设置帐户，并允许他们登录以检查他们的订单状态。

由于数据库中的主键是customer_id，因此如果他们继续使用相同的电子邮件/地址/等创建新帐户，则不应导致冲突，除非您已准备好代码以防止重复。有人创建多个临时帐户的情况很少见，因为使用通过电子邮件发送给他们的密码登录比再次输入数据更容易。

对于后端订单，我们通常以与上述相同的方式为每个客户创建一个帐户。但是，如果他们没有电子邮件地址（或者他们只想通过电话购买），我们会生成一个帐户，其中包含他们的送货信息和一个空白的电子邮件地址（必须编码例外，不发送临时密码/当它是空白时订购确认）。 customer_id将提供给他们，他们的运输信息和公司名称将存储在帐户中以查找并加快将来的订单。

Answer 2

我怀疑这个问题有什么完美的解决方案。您只需做出选择：与不强迫客户完成整个注册流程所带来的转化率相比，保证可识别的客户历史记录有多重要。

如果您没有强制注册，您将无法100％识别回头客。有人可能会争辩说，即使 注册也是不可能的，因为用户有时会因各种原因选择创建新帐户。但是，通过了解您已有的数据，您可以做一些“足够好”的事情。

例如，在某些国家/地区，邮政编码非常具体。它们足够具体吗？取决于您经营的国家以及您的客户群的构建方式。如果你每个家庭往往只有一个用户，也许。

或者，根据您支持的付款方式，您可以考虑构建信用卡号的单向散列（“伪唯一ID”）。一些支付解决方案确实会返回一个独特的“付款人ID”，这可能是完美的 - 假设您从所支持的所有支付服务中获得了一些东西。

Answer 3

我会指定一个唯一的客户ID来保存数据，然后在未来的购买中，相同的匿名购买者可以查看相同的电子邮件地址和/或地址和邮政编码的第一行是否已存在。如果您要求提供电话号码，请进行比较。基本上你需要一些相当独特的东西，同时摆脱可能的错误（例如，只看地址的第一行 - 很可能有一个以上的123大街！但是只有一条123大街有邮政编码ABC123 ）。

一旦你知道这一点，你就可以自动创建一个帐户 - 向客户发送一封电子邮件，说明你已经注意到他们之前购买过，并节省时间使用这个电子邮件地址和这个自动生成的密码。当他们第一次登录时，进行快速安全检查（可能是最后一张发票的价值），然后让他们检查他们的详细信息。您甚至可以在结账过程中执行此操作。我认为通过表明你可以自动节省时间可以节省时间。

如果您不想这样做，那么就可以设置一个cookie，但如果您是在欧盟境内进行交易（cookie法则），则必须警告用户。

有人拥有不同的电子邮件地址和邮政地址的问题可能是他们订购商业，然后他们可以订购供个人使用（很难说，因为我们不知道你在卖什么）。

Answer 4

当然，您可以使用Cookie跟踪销售会话。但也要注册匿名用户到您的网站，但不要让他们意识到他们正在填写任何注册表。让他们按照销售过程，在销售过程结束时生成一个唯一的客户ID并通过电子邮件发送，并显示该通知在网站完成销售后，只需输入客户ID即可登录网站。

Answer 5

我通常使用用户IP，我创建一个只有ID和他的IP地址的帐户。当他注册时，我只是更新他的记录。可以（也应该）使用除IP之外的其他东西，比如创建一个随机令牌以放入cookie以绕过正在使用的任何会话系统，这样你可以使它持续更长时间。例如。

现在，在应用程序中，您必须使您的用户类能够使用此IP /令牌，真实会话或您可能拥有的任何其他登录系统来“识别”您的用户。

Answer 6

我这样做的方式是：完全没有。

简单地说，让人们通过paypal或任何您付款的方式付款并从那里获取数据，在使用提供的API处理付款后自动创建用户和订单。

此时您拥有所需的所有信息，并且可以存储足够的信息用于统计/电子垃圾邮件营销。

保持简单，不需要任何人，甚至没有人输入客户ID或电子邮件，他们都会喜欢它。

这样做我仍然感受到我可能感兴趣的所有信息，并且用户体验尽可能快速/轻松。

Answer 7

嗯...我们为访客用户生成一个uniq ID - 用户名的哈希值或uuid，并将此一个存储在购物篮表中。如果您不介意使用此类数据使数据库混乱，您也可以在customer表中进行冷存储。 uuid存储在客户浏览器的cookie中，直到他签出篮子。如果用户决定稍后/在签出购物篮之前注册，那么cookie的内容也非常适合将匿名帐户（及其篮子的内容）分配给有效帐户。

Answer 8

我会创建一个唯一的客户ID，并将其作为cookie存储在用户的计算机上。这应该会减少具有多个客户ID的用户数量。

但严肃地说，只要你的数量不会达到数十万（并且恭喜！），只要你对客户有适当的索引，就不会损害你的数据库。 id列。

如果你的每个客户都有id = 0，你会不会有尽可能多的行？如果您想保留所有数据，我认为这是不可避免的，对吧？零id可能会导致索引出现额外问题。