我们的应用程序在其他功能中有一个在线商店，通常要求用户在完成销售之前注册，在此过程中创建唯一的customer_ID。当他们返回时，他们可以登录，他们的联系方式和交易历史记录将从数据库中检索。
我们现在正在探索在"匿名"或"客人"客户的情况下该怎么做，向不想注册的客户开放在线商店，以及在后端应用程序中登录的销售，其中获取客户的电子邮件，邮政地址等太耗时了。该解决方案在网上商店之外也有应用。
多个公司使用相同的数据库，数据库是建立在一个政党模型结构上的，所以我们已经探索了几个选项:
- 在
transaction表中将所有匿名客户存储在一个预定义的customer_ID下;-
customer_ID = 0对应每个匿名用户，customer_ID > 0对应每个真实用户- 这是直接硬编码到应用程序
- 但更涉及到确定哪些客户属于哪个公司
-
customer_ID = 0的详细信息应该存在于数据库中的customer表中还是作为应用程序中的对象?- 如果在数据库中，可以进行哪些数据库级约束以确保它始终存在?
- 如果不在数据库中，那么从
transaction.customer_ID到customer.customer_ID的外键约束不再工作
-
-
customer_ID与公司party_ID相同- 更容易确定每个公司的总销售额等
- 这会使事情变得混乱，因为看起来公司是自己的客户，而不是其他独特的客户
customer_ID- 如果相同的物理用户返回怎么办?将有许多记录重复相同类型的数据;电子邮件、收货地址等
- 不总是可靠的，因为人们有时使用多个电子邮件地址，或留下旧的地址。
- 如果没有电子邮件地址，就像车间的情况一样，形式发票等?
添加
在其他地方已经建议了#2和#3的组合-尝试为每个客户存储单个记录，如果可能的话使用电子邮件地址，或者在每次访问时使用新记录。
我应该指出，我们不需要为每个匿名客户存储记录，但似乎关系数据库是为了处理关系而构建的，因此在transaction表中有一个NULL或customer_ID，不引用实际的客户记录似乎是错误的…
我还必须强调，这个问题的目的是确定在现实世界中有什么解决方案来记录没有邮政地址或电子邮件地址的"随意"交易(想象一下超市结账)，以及在线商店交易(无论是否存储电子邮件地址和邮政地址)。
过去SO社区使用了哪些解决方案?
假设您需要一个电子邮件地址来处理所有在线订单，您可以在每个客户完成订单时为他们创建一个临时帐户。
这可以通过使用收货地址和结账时提供的其他信息来填写帐户，并通过电子邮件随机发送临时密码给他们(如果该功能内置在网站中，可以选择标记它以要求在第一次登录时更改)。这只需要他们最少的努力来设置帐户，并允许他们登录来检查他们的订单状态。
由于数据库中的主键是customer_id，如果他们继续使用相同的电子邮件/地址/等创建新帐户，它应该不会引起冲突，除非您已经有代码来防止重复。不过，很少有人创建多个临时帐户，因为使用电子邮件发送给他们的密码登录比再次输入数据更容易。
对于后端订单，我们通常以与上述相同的方式为每个客户创建一个帐户。但是，如果他们没有电子邮件地址(或者他们只想通过电话购买)，我们将生成一个包含他们的运输信息和一个空白电子邮件地址的帐户(必须编写一个异常，以便在该帐户为空白时不发送临时密码/订单确认)。将customer_id提供给他们，并将他们的运输信息和公司名称存储在帐户中，以便查询和加快未来的订单。
我怀疑这个问题没有完美的解决方案。你只需要做一个选择:保证可识别的客户历史与不强迫客户完成完整的注册过程所获得的转化率的提高相比，有多重要?
如果你不强制注册，你将无法识别回头客100%的时间。有人可能会说，即使与注册也不可能，因为用户有时会出于各种原因选择创建新帐户。但是，通过了解已有的数据，您可能能够做一些"足够好"的事情。
例如，在一些国家，邮政编码是非常具体的。它们是否足够具体?这取决于你在哪个国家开展业务，以及你的客户群是如何建立的。如果你倾向于每户只有一个用户，也许。
或者根据您支持的支付方式，您可以考虑构建信用卡号码的单向散列("伪唯一ID")。有些支付解决方案实际上会返回一个唯一的"付款人ID"，这可能是完美的——假设你从你支持的所有支付服务中获得一些东西。
我将分配一个唯一的客户ID来保存数据，然后在同一匿名购买者将来购买时，您可以查看是否已经存在相同的电子邮件地址和/或地址和邮政编码的第一行。如果你要电话号码，比较一下。基本上，你需要一些相当独特的东西，同时摆脱可能的错误(例如。只看地址的第一行——很可能不止一条123 Main Street!但是只会有一条邮政编码为ABC123的123 Main Street。
一旦你知道了这一点，你可以自动为他们创建一个帐户——给客户发一封电子邮件，说你已经注意到他们以前购买过，为了节省他们的时间，使用这个电子邮件地址和这个自动生成的密码。当他们第一次登录时，做一个快速的安全检查(可能是上一个发票的价值)，然后让他们检查他们的详细信息。您甚至可以在结帐过程中这样做。我认为，通过自动完成任务来显示你可以节省他们的时间，这可能是一种奖励。
如果你不想这样做，那么你可以设置一个cookie，尽管你必须警告用户，如果你是从欧盟内部进行交易(cookie法律)。
一个人有不同的电子邮件地址和邮政地址的问题，可能是他们为商业订购，然后他们可以为个人使用订购(很难说，因为我们不知道你在卖什么)。
当然，您可以通过使用cookie来跟踪销售会话。但也要注册匿名用户到你的网站，但不要让他们意识到他们正在填写任何注册表格。让他们遵循销售过程，在销售过程结束时生成一个唯一的客户id，给他们发电子邮件，并在他们完成销售后在网站上显示该通知，让他们通过输入他们的客户id登录到网站。
我通常使用用户IP，我创建一个帐户，只有一个ID和他的IP地址。当他注册时，我就更新他的记录。除了IP之外的其他东西也可以(也应该)被使用，比如创建一个随机令牌放在cookie中，以绕过任何正在使用的会话系统，这样你就可以让它持续更长时间。
现在，在应用程序中，您必须使您的用户类能够使用此IP/令牌、真实会话或您可能拥有的任何其他登录系统来"识别"您的用户。
嗯…我们为来宾用户生成一个惟一ID——用户名的哈希值或uuid，并将其存储在篮表中。如果您不介意在数据库中塞满此类数据，也可以将这些数据冷存储在customer表中。uid存储在客户浏览器中的cookie中，直到他签出购物篮。如果用户决定稍后/在结账购物篮之前注册，那么cookie也可以很好地将匿名帐户(及其购物篮的内容)分配给有效帐户。
我将创建一个唯一的客户ID，并将其作为cookie存储在用户的机器上。这将减少具有多个客户id的用户数量。
但是，严肃地说，只要id的数量没有达到数十万(如果达到了，恭喜!)，只要在客户id列上有适当的索引，就不会损害数据库。
如果每个客户的id=0，那么您不会有同样多的行吗?如果你想保留所有的数据，这是不可避免的，对吧?0 id也可能会给索引带来额外的问题。
我的做法是:一点也不。
简单地说，让人们通过paypal或其他支付解决方案进行支付，并从中获取数据，在使用提供的API处理支付后自动创建用户和订单。
在这一点上，你有所有你需要的信息，绝对可以存储足够的你的统计/电子垃圾邮件营销。
保持简单，什么都不需要，甚至不需要人们输入客户id或电子邮件，他们都会喜欢的。
这样做，我仍然有每一点我可能感兴趣的信息，用户体验是尽可能快速/简单。