Deve registos no site ser armazenados em uma tabela separada para usuários ativos?

Question

Eu estou querendo saber sobre as melhores práticas para o registro do usuário. Estou inclinado para armazenar registros do site em uma tabela de registros separado e, em seguida, uma vez que a inscrição foi confirmada por e-mail transferir os dados para a tabela de usuários.

O benefício para isso seria que lê da tabela de usuários não estão desordenado com inscrições não ativados. Outro benefício é que o campo de e-mail (nome de usuário) pode permanecer única na tabela de usuários, mas se você tentar registrar com um endereço de e-mail que você não próprio, o proprietário do endereço de e-mail ainda será capaz de registrar com ele como o campo email não será único na tabela de registros.

Eu estou querendo saber se esta é uma prática comum, ou se há alguma razão que esta não é uma boa ideia?

Answer 1

ativado ou não

Não há nenhuma necessidade real para armazenar um usuário em uma tabela diferente. Apenas armazenar todos os usuários em uma tabela, com um sinalizador booleano que indica se o seu ativado ou não. De vez em quando executar um trabalho cron para verificar e ver se há contas que são x dias de idade e não ativado e excluí-los.

E-mail

Então, provavelmente você está ativando o usuário da direita e-mail? Você também quer configurá-lo para que se outro usuário entrou e-mail de outra pessoa que outra pessoa ainda pode registrar correto? Isso é realmente bastante simples de fazer. Em que o e-mail que é erroneamente enviado a eles, só tem um link para remover o e-mail de seu banco de dados porque, obviamente, não é deles e eles nunca vão para ativar a conta.

Mas e se o outro cara só exclui-lo?

Então, quando eles registrar dizer-lhes que você já tem o seu e-mail e oferta para enviar a ativação novamente, este e-mail também terá a opção de removê-lo do banco de dados.

ou

Basta remover a conta mais velho do banco de dados. Lógico se a pessoa está tentando ativar uma nova conta e há um velho, que nunca ativada, você pode simplesmente removê-lo.

Answer 2

Eu acho que seria mais de engenharia.

contas de loja todos eles em uma mesa e agendar uma consulta SQL (todos os dias) para excluir não activas do mais de 30 dias.

Answer 3

Faça um favor e mantê-lo uma única tabela. Você simplesmente não vai ter inscrições abortados suficientes para problemas de desempenho de entrar em jogo (especialmente se você limpá-los depois de 3 semanas).

A sua justificação sobre os endereços de e-mail é bobagem. Ninguém é susceptível de obter o seu e-mail bloqueado por um falso registro.

Answer 4

Pode haver um caso em que você logicamente dividir as duas tabelas: Se o seu processo de registo pede um monte de informações de usuário obrigatório somente depois que você confirmou o endereço de e-mail. Por exemplo, se sua tabela de registro pendente acabaria com apenas algumas colunas, tais como e-mail e chave de ativação enquanto que seus usuários tabela tem muitas colunas adicionais, como nome de usuário, nome, sobrenome, endereço postal, etc.

A divisão pode fazer sentido nesse caso, como você seria capaz de declarar as colunas NOT NULL.

Além disso, porém, eu tenho que concordar com a maioria das outras respostas; soa como otimização prematura para mim. Várias tabelas com a mesma estrutura é um sinal de alerta forte que ur fazendo isso errado. não definitiva, mas um aviso forte.

Answer 5

Eu concordo com esta prática para a separação de razões Preocupações: "processo de registro" A e "contas de usuário" são dois conceitos diferentes

.

A tabela de registro seriam usados ??para persistir o estado do "processo de registro". Uma vez que o processo está completo (uma vez que o email é validado), "output" do processo seria uma nova "conta de usuário". Se o processo falhar (por exemplo, "tempos de espera" depois que o usuário não confirmar o seu e-mail para 1 mês), não há impacto sobre o conceito de "conta de usuário".

Como foi dito em outra resposta, este pode ser mais de engenharia, em alguns casos, mas também pode ser uma maneira útil de complexidade enapsulate destes dois conceitos distintos. Ele também pode ser visto como contradizendo os princípios de normalização, mas então eu acredito que você tem que escolher uma troca entre encapsulamento e normalização dependendo do seu contexto.