我们现在正在探索在“匿名”或“客户”客户的情况下做什么,向不想注册的客户开放网上商店,以及登录后端应用程序的销售,电子邮件,邮寄地址等都太耗时了.该解决方案也在网上商店以外的应用程序.
多个公司使用相同的数据库,数据库建立在party model结构上,因此我们已经探索了几个选项：
>将所有匿名客户存储在事务表中的一个预定义的customer_ID下：
> customer_ID = 0,每个匿名用户,customer_ID>每个真实用户为0
>这是直接的硬编码到应用程序
>但更多的参与确定哪些客户属于哪家公司
> customer_ID = 0的详细信息是否存在于数据库中的客户表中或作为应用程序中的对象？
>如果在数据库中,可以做什么数据库级的约束来确保它始终存在？
>如果不在数据库中,则外键约束从transaction.customer_ID到customer.customer_ID不再工作
> customer_ID与公司party_ID相同
>更容易确定每个公司的总销售额等
>这会使事情变得混乱,因为公司是自己的客户,而不是其他独特的客户
>为每个新的匿名客户生成一个唯一的customer_ID(每个会话)
>如果同一个物理用户返回怎么办？将有许多记录重复相同类型的数据;电子邮件,送货地址等
>使用另一个唯一的键,例如电子邮件地址来引用客户
>不总是可靠的,因为有时使用多个电子邮件地址,或者留下旧地址.
>如果没有电子邮件地址被采取,如车间的情况,备考发票等等呢？
>其他一些Stack Overflow启发的解决方案！
加成
在其他地方已经提出了#2和#3的组合 – 试图为每个客户存储单个记录,如果可能的话,使用电子邮件地址,或者如果不是,每次访问都会有新的记录.
我应该指出,我们不需要为每个匿名客户存储记录,但似乎关系数据库是为处理关系而构建的,因此在事务表中没有引用NULL或customer_ID.一个实际的客户记录似乎错了…
我还必须强调,这个问题的目的是确定什么现实的解决方案是记录“休闲”交易,没有邮寄地址或电子邮件地址(想象一个超市chekout)以及在线商店交易,电子邮件地址和给出邮政地址是否存储.
过去,SO社区使用了哪些解决方案？
这可以通过使用送货地址和在结帐时提供的其他信息来填写帐户,并向其发送随机临时密码(可选地将其标记为要在第一次登录时更改,如果该功能已构建)进入网站).这需要尽可能少的努力来设置帐户,并允许他们登录以检查其订单状态.
由于您的数据库中的主键是customer_id,如果他们继续使用相同的电子邮件/地址/ etc等新帐户,则不应该导致冲突,除非您已经有代码来防止重复.有人创建多个临时帐户是很少见的,因为使用电子邮件发送的密码更容易登录,而不是再次输入数据.
对于后端订单,我们通常以与上述每个客户相同的方式创建一个帐户.但是,如果他们没有电子邮件地址(或者他们只想通过电话购买),我们会生成一个帐户,其中包含运送信息和一封空白的电子邮件地址(必须编写一个例外以不发送临时密码/订单确认时为空白). customer_id给他们,他们的运输信息和公司名称存储在帐户中以查找并加快未来的订单.