我们的应用程序具有在线商店等功能，通常会要求用户在完成销售之前注册，从而创建一个独特的customer_ID正在进行中。当他们返回时，他们可以登录并从数据库中检索他们的联系方式和交易历史记录。
我们现在正在探索在“匿名”或“访客”客户的情况下该怎么做，向不想注册的客户开放在线商店，以及在后端应用程序中登录的销售，其中获取客户的电子邮件、邮政地址等太耗时了。该解决方案在在线商店之外也有应用。
多个公司使用同一个数据库，并且该数据库建立在一个派对模型 https://stackoverflow.com/questions/716549/what-are-the-principles-behind-and-benefits-of-the-party-model结构，所以我们探索了一些选择：
- Store all anonymous customers under one pre-defined
customer_ID in the transaction table:
-
customer_ID = 0 for every anonymous user, and customer_ID > 0 for every real user
- 这可以直接硬编码到应用程序中
- 但更多涉及确定哪些客户属于哪个公司
- Should details for
customer_ID = 0 exist in the customer table in the database or as an object in the application?
- 如果在数据库中，可以做哪些数据库级别的约束来保证它始终存在？
- 如果数据库中没有，则外键约束来自
transaction.customer_ID to customer.customer_ID不再工作
-
customer_ID is the same as the company party_ID
- 更容易确定每个公司的总销售额等
- 这会让事情变得混乱，因为看起来该公司是自己的客户，而不是其他独特的客户
- Generate a unique
customer_ID for every new anonymous customer (per session)
- 如果同一个物理用户返回怎么办？会有很多记录重复同一种数据；电子邮件、送货地址等
- Use another unique key, such as email address, to refer to a customer
- 并不总是可靠，因为人们有时会使用多个电子邮件地址，或留下旧地址。
- 如果没有电子邮件地址（就像车间、形式发票等那样）怎么办？
- 其他一些受 Stack Overflow 启发的解决方案！
Addition
其他地方已经建议将 #2 和 #3 结合起来 - 尝试为每个客户存储一条记录，如果可能的话使用电子邮件地址，或者如果不可能的话，在每次访问时都存储一个新记录。
我应该指出我们不need为每个匿名客户存储一条记录，但似乎关系数据库是为了处理关系而构建的，因此有 NULL 或customer_ID in the transaction未引用实际客户记录的表似乎是错误的......
我还必须强调，这个问题的目的是确定有哪些现实世界的解决方案可以记录没有给出邮政地址或电子邮件地址的“临时”交易（想象一下超市结账）以及提供电子邮件地址和电子邮件地址的在线商店交易。无论是否存储，都会给出邮政地址。
SO 社区过去使用过哪些解决方案？
假设您需要所有在线订单的电子邮件地址，您可以在每个订单完成时为每个未登录的客户创建一个临时帐户。
这可以通过使用结账时提供的送货地址和其他信息来填写帐户，然后通过电子邮件向他们发送随机临时密码（可以选择将其标记为需要在首次登录时更改，如果构建了该功能）进入网站）。这需要他们花费最少的精力来设置帐户，并允许他们登录以检查其订单状态。
由于数据库中的主键是 customer_id，因此如果他们继续使用相同的电子邮件/地址/等创建新帐户，则不会导致冲突，除非您已经有代码来防止重复。不过，很少有人创建多个临时帐户，因为使用通过电子邮件发送给他们的密码登录比再次输入数据更容易。
对于后端订单，我们一般会按照上述相同的方式为每个客户创建一个账户。但是，如果他们没有电子邮件地址（或者他们只想通过电话购买），我们会使用他们的送货信息和空白电子邮件地址生成一个帐户（必须编写例外情况以不发送临时密码） / 空白时的订单确认）。向他们提供 customer_id，他们的运输信息和公司名称存储在帐户中，以查找和加快未来的订单。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
