Mise en œuvre de la conception des tables SQL

Question

Je suis novice en SQL et j'ai reçu une tâche. Voici les détails:

Ce que je:

1. application de bureau AC# statut de connexion de l'utilisateur et la vue de l'utilisateur (seulement deux options: connexion d'un utilisateur et vérifier l'état de tous les utilisateurs qui sont factices créé)

2. Une table nommée USER contenant

   • id
   • nom d'utilisateur
   • DateCreated

3. Une table nommée LOGINSTAT contenant

   • id
   • nom d'utilisateur
   • Logtime
   • LogDate

Ce que je dois mettre en œuvre

Je dois gagner du temps et la date lorsque les journaux jamais utilisateur dans la table dans LOGINSTAT en utilisant SQL.

Ma question

Ma question est de savoir comment puis-je mettre en oeuvre. Je peux faire le codage, mais je suis intéressé à obtenir de bons conseils pour l'implémenter. Je le considère comme une façon formelle comme je sais de le faire:

lorsque l'utilisateur se connecte dans les valeurs d'insertion dans la table de connexion donnant toutes les valeurs requises.

MAIS

Je pense que peut-être un peu bizarre. Certains de mes amis ont dit que vous pourriez être en mesure de l'implémenter en utilisant une clé étrangère et des clés primaires, mais le problème est que l'utilisateur peut se connecter plusieurs fois par jour. Comment suivre l'heure et la date de connexion dans ce cas?

Answer 1

Vous n'avez pas besoin de nom d'utilisateur dans votre table LOGINSTAT.

Vous voudrez probablement le LOGINSTAT à inclure:

• id
• u_id
• loginDateTime

id est l'identifiant unique de chaque connexion
u_id est une clé étrangère de l'ID des utilisateurs qui correspond à votre événement de journal à un utilisateur
loginDateTime est une date-heure qui donnera vous à la fois votre date de journal et l'heure du journal dans une colonne

Answer 2

Qu'est-ce qui est unique dans LOGINSTAT? Pas utilisateur en soi, mais ID + LogDate + LogTime devrait être. Ce serait votre clé primaire.

La seule clé étrangère se trouve dans LOGINSTAT: ID, qui référence l'ID dans la table USER.

Answer 3

Les valeurs d'une colonne PRIMARY KEY (par exemple USER.id) doivent être uniques les unes des autres.

Valeurs dans une colonne FOREIGN KEY dans un autre tableau faisant référence à cette clé primaire (par exemple, LOGINSTAT.id faisant référence à USER.id) n'ont pas besoin d'être uniques - vous pouvez avoir plusieurs enregistrements dans une table dont la même référence correspond à la même clé primaire.