在数据库中存储有关匿名/访客用户的信息的方法有哪些？ [英] What ways are there to store information about an anonymous/guest user in a database?

问题描述

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

我们现在正在探索如何处理匿名 或客户客户，向不想注册的客户开放在线商店，以及登录后端应用程序的销售，其中接收客户的电子邮件，邮寄地址等太费时。该解决方案也在网上商店以外的应用程序。

多个公司使用相同的数据库，数据库建立在 party model 的结构，所以我们探讨了几个选项：

1. 将所有匿名用户存储在事务中的一个预定义的 customer_ID / code>表：
   
   
   
   1. customer_ID = 0 每个匿名用户， customer_ID> 0 对于每个真实用户
      
      
      
      • 这是直接硬编码到应用程序
      
      
      • 但是更多参与确定哪些客户属于哪家公司
      
      
      • 应该在客户中存在 customer_ID = 0 的详细信息数据库中的表或应用程序中的对象？
        
        
        
        • 如果在数据库中，可以采取什么数据库级限制来确保它始终存在？
        
        
        • 如果不在数据库中，那么从 transaction.customer_ID 到 customer.customer_ID 不再工作的外键限制
        
        
      
      
   
   
   2. customer_ID 与公司 party_ID
      
      
      
      • 更轻松地确定每个公司的总销售额等。
      
      
      • 这会混淆事项因为看起来公司是自己的客户，而不是其他独特的客户
      
      
   
   


<为每个新匿名客户生成一个唯一的 customer_ID



• 如果同一个物理用户返回，怎么办？将有许多记录重复相同类型的数据;电子邮件，送货地址等。




2. 使用另一个唯一的密钥，如电子邮件地址来引用客户
   
   
   
   • 不总是可靠的，因为有时使用多个电子邮件地址，或者留下旧地址。
   
   
   • 如果没有电子邮件地址，如在车间的情况，备考发票等？
   
   


3. 其他一些Stack Overflow启发式解决方案！

加号

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

我应该指出我们不需要为每个匿名客户存储记录，但似乎关系数据库被构建为处理关系，因此具有NULL或 customer_ID 在交易表中，不引用实际的客户记录似乎错误...

$ b $我还必须强调，这个问题的目的是确定什么现实的解决方案是记录休闲交易，没有邮寄地址或电子邮件地址（想象一个超市chekout）和网上商店交易，给出电子邮件地址和邮政地址是否存储。

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

解决方案

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

可以使用送货地址和结帐时提供的其他信息来填写帐户，并通过电子邮件发送随机临时密码（可选地标记）它要求在第一次登录时进行更改，如果该功能内置到网站中）。这需要很少的努力来设置帐户，并允许他们登录以检查其订单状态。

由于数据库中的主键是customer_id，如果他们继续使用相同的电子邮件/地址/ etc等新帐户，那么它不应该引起冲突，除非你已经有代码来防止重复。有一个人创建不止一个临时帐户是很少见的，因为使用电子邮件发送的密码更容易登录，而不是再次输入数据。

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

Our application has an online shop among other features, and users are normally requested to register before completing a sale, creating a unique customer_ID in the process. When they return, they can log in and their contact details and transaction history are retrieved from the database.

We are now exploring what to do in the case of an 'anonymous' or 'guest' customer, opening up the online shop to customers who don't want to register, and also for sales logged in the backend application, where taking the customer's email, postal address, etc is just too time consuming. The solution has applications outside the online shop too.

Multiple companies use the same database, and the database is built on a party model structure, so we have explored a few options:

1. Store all anonymous customers under one pre-defined customer_ID in the transaction table:
   1. customer_ID = 0 for every anonymous user, and customer_ID > 0 for every real user
      • This is straight-forward to hard-code into the application
      • But more involved to determine which customers belong to which company
      • Should details for customer_ID = 0 exist in the customer table in the database or as an object in the application?
        • If in the database, what database-level constraints can be made to ensure that it always exists?
        • If not in the database, then foreign key constraints from transaction.customer_ID to customer.customer_ID no longer work
   2. customer_ID is the same as the company party_ID
      • Easier to determine aggregate sales for each company, etc
      • This would confuse matters as it would appear that the company is its own customer, rather than other unique customers

2. Generate a unique customer_ID for every new anonymous customer (per session)
   • What if the same physical user returns? There will be many records repeating the same sort of data; email, shipping address, etc.
3. Use another unique key, such as email address, to refer to a customer
   • Not always reliable as people sometimes use more than one email address, or leave old addresses behind.
   • What if there is no email address to be taken, as is the case on the shop floor, pro forma invoices, etc?
4. Some other Stack Overflow inspired solution!

Addition

A combination of #2 and #3 has been suggested elsewhere - attempt to store a single record for each customer, using the email address if possible, or a new record on every visit if not.

I should point out that we don't need to store a record for every anonymous customer, but it just seems that the relational database was built to deal with relationships, so having a NULL or a customer_ID in the transaction table that doesn't reference an actual customer record just seems wrong...

I must also stress that the purpose of this question is to determine what real-world solutions there are to recording 'casual' transactions where no postal address or email address are given (imagine a supermarket chekout) alongside online shop transactions where an email address and postal address are given whether they are stored or not.

What solutions have the SO community used in the past?

解决方案

Assuming you require an e-mail address for all online orders, you could create a temporary account for every customer at the completion of each order when they are not logged in.

This can be done by using the shipping address and other information provided during checkout to fill in the account, and e-mailing a random temporary password to them (optionally flagging it to require changing on the first log-in, if that functionality is built into the website). This requires minimal effort on their part to setup the account, and allows them to sign in to check their order status.

Since the primary key in your database is the customer_id, it should not cause conflicts if they continue making new accounts with the same e-mail/address/etc, unless you have code in place to prevent duplicates already. It's rare for someone to create more than one temporary account though, since it's easier to log in with the password e-mailed to them than entering their data again.

For the backend orders, we generally create an account in the same way as above for every customer. However, if they don't have an e-mail address (or they only want to purchase by phone), we generate an account with their shipping information and a blank e-mail address (have to code an exception to not send temporary passwords/order confirmations when it's blank). The customer_id is given to them, and their shipping information and company name are stored in the account to look up and expedite future orders.

这篇关于在数据库中存储有关匿名/访客用户的信息的方法有哪些？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！