有哪些方法可以在数据库中存储有关匿名/来宾用户的信息？
我们的应用程序具有在线商店等功能，通常会要求用户在完成销售之前进行注册，并在此过程中创建唯一的 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客户（每个会话）- 如果同一个物理用户返回怎么办？会有很多记录重复同一种数据；电子邮件、送货地址等。
- 使用另一个唯一键（例如电子邮件地址）来引用客户
- 并不总是可靠，因为人们有时会使用多个电子邮件地址，或留下旧地址。
- 如果没有电子邮件地址（如车间、形式发票等），该怎么办？
- 其他一些受 Stack Overflow 启发的解决方案！
添加
已在其他地方建议了 #2 和 #3 的组合 - 尝试为每个客户存储一条记录（如果可能的话使用电子邮件地址），或者如果不行则在每次访问时存储新记录。
我应该指出，我们不需要为每个匿名客户存储一条记录，但似乎关系数据库是为了处理关系而构建的，因此有一个 NULL 或一个 transaction 表中的 customer_ID
我还必须强调，这个问题的目的是确定那里有哪些实际的解决方案记录没有邮政地址或没有邮政地址的“临时”交易电子邮件地址与在线商店交易一起给出（想象一下超市结账），无论是否存储，都会给出电子邮件地址和邮政地址。
SO 社区过去使用过哪些解决方案？
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:
- Store all anonymous customers under one pre-defined
customer_IDin thetransactiontable:customer_ID = 0for every anonymous user, andcustomer_ID > 0for 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 = 0exist in thecustomertable 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_IDtocustomer.customer_IDno longer work
customer_IDis the same as the companyparty_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
- Generate a unique
customer_IDfor 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.
- 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?
- 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
假设您需要所有在线订单的电子邮件地址，您可以在每个订单完成时为未登录的每个客户创建一个临时帐户。
这可以通过使用结账时提供的送货地址和其他信息来完成填写帐户，然后通过电子邮件向他们发送随机临时密码（如果网站内置了该功能，则可以选择将其标记为需要在首次登录时更改）。这需要他们花费最少的精力来设置帐户，并允许他们登录以检查其订单状态。
由于数据库中的主键是 customer_id，因此如果他们继续使用相同的电子邮件/地址/等创建新帐户，则不会导致冲突，除非您已经有代码来防止重复。不过，很少有人会创建多个临时帐户，因为使用通过电子邮件发送给他们的密码登录比再次输入数据更容易。
对于后端订单，我们一般会按照上述相同的方式为每个客户创建一个账户。但是，如果他们没有电子邮件地址（或者他们只想通过电话购买），我们会使用他们的送货信息和空白电子邮件地址生成一个帐户（必须编写例外情况以不发送临时密码） / 空白时的订单确认）。向他们提供 customer_id，他们的运输信息和公司名称存储在帐户中，以查找和加快未来的订单。
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.
我怀疑这个问题是否有完美的解决方案。您只需做出选择：与不强迫客户完成完整注册流程而提高转化率相比，保证可识别的客户历史记录有多重要。
如果你不强制注册就去，你将无法100%识别回头客。有人可能会说，即使注册也是不可能的，因为用户有时会出于各种原因选择创建新帐户。但是，通过了解已有的数据，您也许能够做一些“足够好”的事情。
例如，在某些国家/地区，邮政编码非常具体。它们足够具体吗？取决于您在哪些国家开展业务以及您的客户群是如何建立的。如果您倾向于每个家庭只有一名用户，也许可以。
或者，根据您支持的付款方式，您可能会考虑构建信用卡号的单向哈希（“伪唯一 ID”）。一些支付解决方案实际上确实会返回一个唯一的“付款人 ID”，这可能是完美的 - 假设您从您支持的所有支付服务中获得了一些东西。
I doubt there are any perfect solutions to this problem. You simply have to make a choice: How important is it to guarantee recognizable customer history in contrast to the improvement in conversions you get from not forcing a customer to go through a full registration process.
If you go without forcing registration, you will not be able to recognize returning customers 100% of the time. One might argue that even with registration that will not be possible, as users sometimes choose to create new accounts for various reasons. But you might be able to do something that's "good enough" by understanding the data you already have.
For example, in some countries, postcodes are quite specific. Are they specific enough? Depends in which countries you operate and also how your customer base is built. If you tend to only have one user per household, maybe.
Or depending on which payment methods you support, you might consider building a one-way hash of the credit card number ("pseudo-unique ID"). Some payment solutions actually do return a unique "payer ID", which could be perfect -- assuming that you get something from all the payment services you support.
我会分配一个唯一的客户 ID 来保存数据，然后在同一匿名购买者将来进行购买时，您可以查看相同的电子邮件地址和/或地址和邮政编码的第一行是否已存在。如果您要电话号码，请进行比较。基本上，您需要一些相当独特的东西，同时消除可能的错误（例如，仅查看地址的第一行 - 很可能有多个 123 Main Street！但只有一个邮政编码为 ABC123 的 123 Main Street ）。
一旦您知道这一点，您就可以自动为他们创建一个帐户 - 向客户发送一封电子邮件，说明您注意到他们之前购买过，并使用此电子邮件地址和此自动生成的密码来节省他们的时间。当他们第一次登录时，进行快速安全检查（可能是最后一张发票的价值），然后让他们检查他们的详细信息。您甚至可以在结帐过程中执行此操作。我认为通过向他们展示你可以通过自动执行来节省他们的时间可能是一个额外的好处。
如果您不想这样做，则可以设置 cookie，但如果您在欧盟境内进行交易，则必须警告用户（cookie 法）。
拥有不同电子邮件地址和邮政地址的人的问题可能是他们出于商业目的订购，然后他们可以出于个人用途订购（很难说，因为我们不知道您在销售什么）。
I would assign a unique Customer ID to save the data, and then on future purchases that the same anonymous purchaser makes you could look to see if the same email address and/or first line of the address and post code already exists. If you ask for a phone number, compare that. Basically you need something fairly unique whilst getting rid of possible errors (eg. only looking at first line of the address - it's very likely that there is more than one 123 Main Street! But there will be only one 123 Main Street with post code ABC123).
Once you know this, you could automatically create them an account - sending the customer an email saying that you've noticed that they purchased previously, and to save them time use this email address and this automatically generated password. When they login for the first time, do a quick security check (maybe value of last invoice), then let them check their details. You could even do this during the checkout process. I think by showing that you can save them time by doing it automatically could be a bonus.
If you don't want to do this, then it's possible to set a cookie, though you'd have to warn the user if you are trading from within the EU (cookie laws).
The problem with someone having different email address and postal address, could be that they order for business, then they could order for personal use (hard to say as we don't know what you're selling).
当然，您可以使用 cookie 跟踪销售会话。但也要在您的网站上注册匿名用户，但不要让他们意识到他们正在填写任何注册表。让他们遵循销售流程，并在销售流程结束时生成一个唯一的客户 ID 并向他们发送电子邮件，并显示该通知在他们完成销售后在网站上，让他们只需输入客户 ID 即可登录网站。
Ofcourse you can track the sale session by using cookies. but Also register anonymous users to your site but don't let them realize that they are filling any registration form .Let them follow the sale process and at the end of the sale process generate a unique customer id and email them and also display that notification on the site after they complete their sale and make them login into the site by just entering their customer id.
我通常使用用户IP，我只用ID和他的IP地址创建一个帐户。当他注册时，我只是更新他的记录。也可以（并且应该）使用 IP 之外的其他东西，例如创建一个随机令牌放入 cookie 中以绕过任何正在使用的会话系统，这样您就可以使其持续更长时间。
现在，在应用程序中，您必须使您的用户类能够使用此 IP/令牌、真实会话或您可能拥有的任何其他登录系统“识别”您的用户。
I usually use the user IP, I create an account with just an ID and his IP address. When he registers, I just update his record. Other things than IP could (and should) be used too, like creating a random token to put in a cookie to bypass any session system in use so you can make it last longer for example.
Now, in the application, you have to make your user class able to "identify" your users with either this IP/token, a real session or any other login system you may have in place.
嗯……我们为来宾用户生成一个 uniq ID——用户名的哈希值或 uuid，并将其存储在购物篮表中。如果您不介意这些数据弄乱您的数据库，您也可以将其冷存储在客户表中。 uuid 存储在客户浏览器的 cookie 中，直到他签出购物篮。如果用户决定稍后/在签出购物篮之前注册，则 cookie 也非常适合将匿名帐户（及其购物篮中的内容）分配给有效帐户。
Mmmm ... we generate a uniq ID for guest users -- a hash-value or uuid for the username and store this one in the basket table. You cold store this also in the customer table, if you don't mind cluttering your database with such data. The uuid is stored in a cookie in the customers browser, until he checks out the basket. The cookie thing is also nice for assigning the anonymous account (and the content of it's basket) to a valid account, if the user decided to register later on / before checking out the basket.
我将创建一个唯一的客户 ID，并将其作为 cookie 存储在用户的计算机上。这应该会减少具有多个客户 ID 的用户数量。
但严肃地说，只要您的 id 数量没有达到数十万（如果是的话，恭喜您！），只要您在客户 id 列上拥有适当的索引，就不会损害您的数据库。
如果每个客户的 id=0 ，那么行数不是一样多吗？我认为如果你想保留所有数据，这是不可避免的，对吧？零 id 也可能会导致索引出现额外问题。
I would create a unique customer ID, and store it on the user's machine as a cookie. This should decrease the number of users with multiple customer IDs.
But in all seriousness, as long as your number of ids isn't getting into the hundreds of thousands (and congrats if it is!), it's not going to hurt your database as long as you have proper indexes on the customer id column.
If you had id=0 for each customer wouldn't you have just as many rows though? I think that's inescapable if you want to keep all the data, right? A zero id might cause your index extra problems too.
我的做法是：一点也不。
简而言之，让人们通过 paypal 或任何您作为支付解决方案进行支付，并从那里获取数据，在使用提供的 API 处理支付后自动创建用户和订单。
那时，您就拥有了所需的所有信息，并且绝对可以存储足够的信息来进行统计/电子垃圾邮件营销。
保持简单，不需要任何东西，甚至不需要人们输入客户 ID 或电子邮件，他们都会喜欢它。
这样做我仍然拥有我可能感兴趣的所有信息，并且用户体验尽可能快速/简单。
The way I do it is : Not at all.
Simply put, let people pay through paypal or whatever you put as payment solution and get the data from there, automatically create the user and the order after the payment is processed using the provided API.
At that point you have all the information you need and can definitely store just enough for your statistics / e-spam marketing.
Keep it simple, require NOTHING, not even people to enter a customer id or an e-mail, and they'll all love it.
Doing that I still have every bit of information I could be interested in and the user experience is as fast/easy as can be.