Conception de base de données: Enregistrement et vérification

Question

Est-ce un bon choix d'avoir des utilisateurs non vérifiés dans le users_table ou devrais-je créer un temp_users_table pour ajouter les utilisateurs non vérifiés?

La première option serait de créer la ligne sur le users_table avec une colonne, par exemple, account_activated pour contenir un nombre entier qui définit si le compte est vérifié ou non.

La deuxième option serait d'avoir deux tables identiques, users_table et temp_users_table. Ajout des utilisateurs non vérifiés sur le dernier. Une fois vérifiée, la ligne sera copiée sur le users_table et supprimée de temp_users_table.

Lequel est le meilleur et pourquoi?

Edit:

La deuxième table ne vise pas à rester là pour toujours, il est temporaire et existera que si l'utilisateur n'est pas activé. Lorsque l'utilisateur est activé, il sera migré vers la table "principale" user_table.

Alors:

users_table: Will have the users that have been verified. 
temp_users_table: Will have ONLY the users that are not verified. 

Answer 1

Je vois ceci d'un point de vue différent.

Dans votre situation, une table est probablement assez bonne. Mais il y a d'autres considérations.

1) Volume. Dans une petite table, filtrer sur un drapeau ne va pas affecter de manière significative les performances. Dans une grande table (des millions de lignes), vous devez placer le drapeau dans un index. Mettre un indicateur de cardinalité faible dans un index d'une grande table peut diminuer les performances.

2) Défauts. Avoir un drapeau dans la table exige que presque chaque requête utilise le drapeau. Pour un système assez grand ou complexe, quelqu'un va manquer ce drapeau. La détermination du risque dépend du coût de la sélection accidentelle d'un utilisateur non activé.

Une façon d'atténuer les risques consiste à utiliser des vues. Si vous implémentez une solution à deux tables, utilisez une vue (All_Users) en utilisant UNION ALL. Si vous implémentez une solution à une table, créez une vue pour les utilisateurs activés uniquement et utilisez cette table à la place. Seule la fonctionnalité de maintenance doit modifier les tables principales.

Answer 2

dépend toujours des circonstances, mais j'ai du mal à trouver les circonstances dans lesquelles il serait logique de faire la solution de deux tables.

Answer 3

Convenu à erikkallen

Deux tables identiques meilleures pratiques pour la conception redondante. cela n'a pas beaucoup de sens de vérifier, par exemple, (Pseudo-code):

sql = Sql("SELECT * FROM db_unactivated_users WHERE user_id = X"); 
sql2 = Sql("SELECT * FORM db_activated_users WHERE user_id = X"); 
if (sql) 
{ 
    return "user not activated"; 
} 
elseif (sql2) 
{ 
    return "user activated"; 
} 
else 
{ 
    return "user not found"; 
} 

cette alternative est beaucoup plus rapide et le meilleur de tous, n'a pas besoin de tables redondantes

sql = Sql("SELECT * FROM db_users WHERE user_id = X"); 
if (sql[activated] = 0) 
{ 
    return "user not activated"; 
} 
elseif (sql[activated = 1) 
{ 
    return "user activated"; 
} 
else 
{ 
    return "user not found"; 
} 

j'espère que vous voyez la différence ;-)

et en plus, si vous avez besoin de changer l'état d'un utilisateur de "non activé" à "activé", vous n'avez pas besoin de le supprimer de la table non activée, sauvegarder ses informations temporairement et le réécrire dans le table

avec une table, vous venez de changer 0 à 1 et c'est tout!

donc, au fond, il est simple de math:

2 tables = 2 requêtes 1 table = 1 requête

que l'on est plus rapide? ;-)

Answer 4

De l'information donnée je discuterais sans aucun doute pour la solution d'une table/colonne supplémentaire, à moins qu'il y ait une raison claire de faire autrement. L'inconvénient principal de l'utilisation de deux tables est qu'il deviendra extrêmement facile de corrompre votre base de données avec des identifiants d'utilisateur qui entrent en conflit ou qui ne correspondent pas, en particulier si vos identifiants sont incrémentés automatiquement. Vous devez faire très attention à la façon dont vous déplacez un utilisateur de la table non vérifiée à la table vérifiée. D'un autre côté, avec une table, vos seules modifications de code consisteront à ajouter des filtres pour les utilisateurs vérifiés/non vérifiés dans les instances où vous souhaitez uniquement exécuter une requête sur des utilisateurs vérifiés ou non vérifiés. Par exemple, SELECT pour une vérification de connexion. S'il y a des raisons non mentionnées ci-dessus qui vous conduiraient à utiliser 2 tables faites le nous savoir.

Answer 5

Il existe un scénario où la solution de 2 tables semble toujours valide pour moi. Si vous devez effectuer une sauvegarde pour un formulaire partiellement rempli, permettre aux utilisateurs finaux de se reconnecter et de terminer le processus. Une raison à cela serait que le remplissage partiel devrait permettre que des valeurs nulles soient stockées dans la table et ne puissent donc pas être chargées dans la table principale (tableau 2). apportant ainsi le besoin d'une table de réplique (tableau 1) à créer.

De cette façon:

• Tableau 1: non vérifiées utilisateurs + utilisateurs avec des formulaires partiellement remplis.
• tableau 2: utilisateurs vérifiés, avec des formulaires complètement remplis.