Nosso aplicativo possui uma loja on-line, entre outros recursos, e normalmente é solicitado que os usuários se registrem antes de concluir uma venda, criando um únicocustomer_ID no processo. Quando eles retornam, eles podem efetuar login e seus detalhes de contato e histórico de transações são recuperados do banco de dado

gora estamos explorando o que fazer no caso de um cliente 'anônimo' ou 'convidado', abrindo a loja on-line para clientes que não desejam se registrar e também para vendas registradas no aplicativo de back-end, onde o e-mail, endereço postal etc. do cliente consome muito tempo. A solução também possui aplicativos fora da loja online.

Várias empresas usam o mesmo banco de dados, e o banco de dados é construído com base emparty model estrutura, então exploramos algumas opções:

Armazenar todos os clientes anônimos em um @ predefinicustomer_ID notransaction mesacustomer_ID = 0 para todo usuário anônimo ecustomer_ID > 0 para todo usuário realIsso é fácil de codificar no aplicativoMas mais envolvido para determinar quais clientes pertencem a qual empresaDeve detalhes paracustomer_ID = 0 existe nocustomer tabela no banco de dados ou como um objeto no aplicativo?e no banco de dados, que restrições em nível de banco de dados podem ser feitas para garantir que ele sempre existSe não estiver no banco de dados, as restrições de chave estrangeira detransaction.customer_ID paracustomer.customer_ID não funciona maiscustomer_ID é o mesmo que a empresaparty_IDais fácil de determinar as vendas agregadas para cada empresa, etIsso confundiria as questões, pois parece que a empresa é seu próprio cliente, em vez de outros clientes únicosGere um únicocustomer_ID para cada novo cliente anônimo (por sessão)E se o mesmo usuário físico retornar? Haverá muitos registros repetindo o mesmo tipo de dados; email, endereço de entrega, etc.Utilize outra chave exclusiva, como endereço de e-mail, para se referir a um cliente Nem sempre confiável, pois às vezes as pessoas usam mais de um endereço de e-mail ou deixam endereços antigos para tráE se não houver endereço de e-mail a ser utilizado, como é o caso da fábrica, faturas pró-forma etc.? Alguma outra solução inspirada no Stack Overflow!

Adiçã

Uma combinação dos itens 2 e 3 foi sugerida em outro lugar - tente armazenar um único registro para cada cliente, usando o endereço de e-mail, se possível, ou um novo registro em cada visita, se nã

Devo salientar que não fazemosnecessidad para armazenar um registro para cada cliente anônimo, mas parece que o banco de dados relacional foi criado para lidar com relacionamentos, portanto, é necessário ter um NULL ou umcustomer_ID notransaction tabela que não faz referência a um registro real do cliente parece errado ...

Eu também devo enfatizar que o objetivo desta pergunta é determinar quais soluções do mundo real existem para registrar transações 'casuais' onde nenhum endereço postal ou endereço de e-mail é fornecido (imagine um chekout de supermercado) ao lado de transações de lojas on-line em que um endereço de e-mail e endereço postal são fornecidos, armazenados ou não.

Que soluções a comunidade SO usou no passado?