Table d'utilisateurs temporaires ou table d'utilisateurs légitimes?

Question

J'ai une application web freelance qui permet aux utilisateurs de s'inscrire à des événements. Dans ma base de données, j'ai une table t_events_applicants avec la colonne t_events_applications.user_id avec une contrainte de clé étrangère liée à la colonne t_users.user_id. Cela signifie donc que seuls les utilisateurs enregistrés avec mon application Web peuvent s'inscrire aux événements de mon application Web.

Mon client souhaite maintenant autoriser les utilisateurs non enregistrés, les utilisateurs qui n'ont pas d'entrée dans ma table utilisateur_t, à s'enregistrer pour les événements. Ces utilisateurs non enregistrés doivent uniquement fournir leur nom et leur adresse e-mail pour s'inscrire aux événements.

Dois-je créer une table t_temporary_user avec le nom des colonnes et le courrier électronique, puis supprimer la contrainte t_events_applicants.user_id fk? Ou devrais-je ajouter des utilisateurs non enregistrés à la table t_user, puis ajouter une colonne appelée t_user.type où type peut être 'enregistré' ou 'non enregistré'?

Comment puis-je choisir l'approche à suivre?

Beaucoup de fois, j'hésite avec l'une ou l'autre approche. Je me demande: «Et si, à un moment ultérieur, un utilisateur temporaire est autorisé à devenir un utilisateur pleinement enregistré? Alors peut-être que je devrais avoir seulement une table de t_user, mais je ne me sens pas bien de stocker beaucoup d'utilisateurs temporaires dans t_user. "

Answer 1

Cela ne serait-il pas fondamentalement un rôle?

Créez une table d'utilisateurs, attribuez-lui un nombre de rôles (plusieurs à plusieurs user_roles).
Dans la table des rôles, vous pouvez ajouter un rôle permettant d'enregistrer des événements et des rôles pour différents droits sur le reste de votre site Web.
De cette façon, il est facile de promouvoir les utilisateurs d'événements seulement à des utilisateurs à part entière (ajouter les rôles corrects) et il sera possible d'ajouter d'autres choses plus tard (autres événements, abonnements spéciaux, etc). Il est probable que vous ayez déjà un tel système en place.

Answer 2

Je voudrais aller avec votre deuxième approche: les ajouter dans la même table, mais avec la colonne Type. Si vous créez deux tables utilisateur, vous devrez toujours vérifier les deux pour trouver un utilisateur, etc. Avec deux tables, comment auriez-vous une contrainte de l'utilisateur à quelque chose qu'elles créent? Restez simple, ils sont un utilisateur, juste un type différent.

Si vous avez une date CreateDate ou LastLogin dans la table des utilisateurs (ou d'une autre table), vous pouvez supprimer les utilisateurs temporaires après un certain laps de temps.

Answer 3

Il semble que les utilisateurs enregistrés par rapport aux utilisateurs non enregistrés soient devenus une fausse distinction compte tenu des nouvelles exigences du système. Je les garderais tous ensemble dans une seule table. Conservez les informations d'inscription du site dans un tableau distinct. Vous n'avez même pas besoin d'une colonne de type dans la table combinée, car vous pouvez déterminer si l'utilisateur est enregistré avec une jointure à la table d'inscription du site.