Au cas où les inscriptions du site sont stockés dans une table séparée pour les utilisateurs actifs?

Question

Je me demande sur les meilleures pratiques pour l'enregistrement des utilisateurs. Je penche vers le stockage des enregistrements de site dans une table d'enregistrements séparés, puis une fois que l'inscription a été confirmée par e-mail transférer les données vers la table des utilisateurs.

L'avantage à ce serait qui lit la table des utilisateurs ne sont pas encombrées avec des enregistrements jamais activés. Un autre avantage est que l'e-mail (nom d'utilisateur) champ peut rester unique dans la table des utilisateurs, mais si vous essayez d'enregistrer une adresse e-mail que vous ne possédez pas, le propriétaire de cette adresse e-mail sera toujours en mesure d'enregistrer avec elle comme champ e-mail ne sera pas unique dans la table des inscriptions.

Je me demande si cela est une pratique courante ou s'il n'y a aucune raison pour laquelle ce n'est pas une bonne idée?

Answer 1

Activé ou Non

Il n'y a pas de réel besoin de stocker un utilisateur dans une autre table. Il suffit de stocker tous les utilisateurs dans une table, avec un indicateur booléen indiquant si leur activé ou non. Chaque si souvent exécuter un travail de cron pour vérifier et voir s'il y a des comptes qui sont x jours et non activés et les supprimer.

E-mail

On peut donc supposer que vous activez l'utilisateur du droit e-mail? Vous voulez également le configurer de sorte que si un autre utilisateur est entré quelqu'un e-mail d'autre cette autre personne pourrait encore enregistrer correctement? C'est en fait assez simple à faire. Dans ce courrier électronique qui est envoyé par erreur à eux, ont juste un lien pour supprimer cette e-mail de votre base de données, car évidemment, ce ne sont pas eux et ils ne vont jamais activer le compte.

Mais si l'autre gars supprime juste?

Alors quand ils enregistrent leur dire que vous avez déjà leur e-mail et offrez d'envoyer de nouveau l'activation, cet e-mail aura également la possibilité de le retirer de la base de données.

ou

Il suffit de supprimer le compte plus de la base de données. Si va de soi que la personne essaie d'activer un nouveau compte et il y a un ancien qui n'a jamais activé, vous pouvez simplement le supprimer.

Answer 2

Je pense que ce serait plus technique.

Rangez tous dans une table et de planifier une requête SQL (tous les jours) pour supprimer des comptes non ACTIVÉE plus de 30 jours.

Answer 3

Faites-vous une faveur et garder une seule table. Vous êtes tout simplement pas avoir assez inscriptions avortés pour des problèmes de performance à venir en jeu (surtout si vous les essuyer au bout de 3 semaines).

Votre justification sur les adresses e-mail est stupide. Personne est susceptible d'obtenir leur email bloqué par une inscription fausse.

Answer 4

Il peut y avoir un cas où vous auriez logiquement diviser les deux tables: Si votre processus d'inscription demande beaucoup d'informations utilisateur obligatoire qu'après avoir vérifié l'adresse e-mail. Par exemple, si votre table d'inscription en attente se retrouveraient avec seulement quelques colonnes, comme le courrier électronique et la clé d'activation alors que votre table utilisateurs a beaucoup de colonnes supplémentaires, telles que le nom d'utilisateur, prénom, nom, adresse postale, etc.

La scission pourrait être logique dans ce cas, que vous seriez en mesure de déclarer les colonnes NOT NULL.

Autre que cela, cependant, je suis d'accord avec la plupart des autres réponses; il semble que l'optimisation trop tôt pour moi. Plusieurs tableaux avec la même structure est un signe fort d'avertissement que ur doin mal. Non défini, mais un avertissement fort.

Answer 5

Je suis d'accord avec cette pratique pour la séparation des raisons Préoccupations: Un « processus d'enregistrement » et « comptes utilisateurs » sont deux concepts distincts

.

Le tableau d'enregistrement sera utilisé pour conserver l'état du « processus d'enregistrement ». Une fois que ce processus est terminé (une fois l'e-mail est validée), « la sortie » du processus serait un nouveau « compte utilisateur ». Si le processus échoue (par exemple, « les délais d'attente » après que l'utilisateur ne parvient pas à confirmer son e-mail pendant 1 mois), il n'y a pas d'impact sur le concept de « compte utilisateur ».

Comme cela a été dit dans une autre réponse, cela peut être plus technique, dans certains cas, mais il peut aussi être un moyen utile de enapsulate complexité de ces deux concepts distincts. Il peut également être considéré comme contredisant les principes de normalisation, mais je crois que vous devez choisir un compromis entre l'encapsulation et la normalisation en fonction de votre contexte.