Stockage des utilisateurs dans une base de données

Question

Je me demandais quel était le meilleur moyen de stocker différents types d'utilisateurs dans ma base de données. J'écris une application qui a 4 types principaux d'utilisateur (admin, école, professeur, étudiant). Pour le moment, j'ai une table pour chacun d'entre eux, mais je ne suis pas sûr que c'est le meilleur moyen de stocker des informations sur l'utilisateur. Par exemple ... Permettre aux étudiants de PM un autre étudiant est simple (expéditeur et receveur student_id) mais permettre aux enseignants aux étudiants PM nécessite une autre table (expéditeur ID_enseignant, expéditeur ID_Etudiant).

Tous les utilisateurs doivent-ils être stockés dans une table d'utilisateurs avec un champ user_type? Si c'est le cas, les informations spécifiques à l'enseignant/à l'étudiant devront toujours être stockées dans une autre table.

users 
user_id, password_hash, user_type 

students 
user_id, student_specific_stuff... 

teachers 
user_id, teacher_specific_stuff... 

Comment puis-je arrêter un utilisateur qui a un user_type = étudiant d'être accidentellement entré dans la table des enseignants (comme les deux ont un user_id)

Je veux juste me assurer d'avoir la base de données correcte avant J'y vais plus loin. Merci ...

Answer 1

Vous devez vous demander si un utilisateur doit être d'un (et un seul) de ces types, ou s'il peut avoir zéro ou plus d'un de ces types ... Dans le dernier cas (au moins), vous devez séparer le "utilisateur" du "rôle".

Mais ces questions et d'autres sont généralement mieux traitées dans la phase de conception globale de votre application (définissez les objets de domaine et ses relations), puis mappées sur la base de données. Ainsi, par exemple, vous pouvez décider que l'utilisateur est une entité qui a un ou plusieurs rôles attachés (l'utilisateur a un rôle), ou peut-être que Admin est une sous-classe de l'utilisateur (l'administrateur est un utilisateur). Vous pouvez également jeter un oeil aux implémentations courantes de l'héritage des classes dans les bases de données relationnelles (même si vous ne faites pas explicitement de la POO, même si vous n'optez pas pour la modélisation 'est'), il vous montrera possible alternatives. .. et vous montre qu'il n'y a pas de bonne approche universelle.

Answer 2

Il existe deux stratégies principales pour stocker une hiérarchie de classes dans une base de données, la stratégie de table par hiérarchie et la stratégie de table par classe. Comme vous l'avez suggéré, dans le tableau par hiérarchie, vous avez besoin d'une colonne pour discriminer les classes d'utilisateurs.

Tout se résume à savoir si vous traitez avec des objets qui sont vraiment différents ou ont une base commune. Par exemple, y a-t-il des opérations qui s'appliquent à n'importe quel type d'utilisateur?

C'est souvent subjectif mais presque tout le temps je vais pour la stratégie de table par hiérarchie. Vous trouverez assez souvent le besoin d'interroger tous les utilisateurs ou d'ajouter des clés étrangères à la table des utilisateurs.

En outre, une variante de la table par hiérarchie consiste à joindre des sous-tables pour des classes, par exemple. vous pouvez ajouter une table d'enseignant contenant uniquement les colonnes spécifiques à l'enseignant et utiliser des jointures avec la table utilisateur.

Answer 3

Pour les utilisateurs, vous aurez 2 tables: Utilisateurs et groupes.

pour écrire des données spécifiques sur des entités spécifiques comme des enseignants ou des élèves, utilisez des tables distinctes qui ont toutes une clé étrangère pour l'utilisateur dans la table Utilisateurs.

Answer 4

Votre table principale users doit comporter une colonne user_type_id, qui lie l'utilisateur à son type.Ensuite, lorsque vous insérez un utilisateur, assurez-vous que la valeur correcte est stockée pour son type d'utilisateur.

Pour stocker les données supplémentaires, vous pouvez ajouter une colonne à la table users, appelée extra_information_id (ou quelque chose). Ensuite, vous pouvez avoir 2 autres tables, student_information et teacher_information. Lors de l'insertion/la mise à jour/la sélection d'un utilisateur, vous pouvez utiliser la combinaison de la colonne user_type_id et de la colonne extra_information_id pour déterminer les deux tables d'informations supplémentaires à utiliser pour ces utilisateurs particuliers.

Answer 5

L'utilisation de termes ORM, je mets en œuvre habituellement l'authentification de la manière suivante:

user = id, user id/name, password, created datetime, updated datetime, last login datetime 

user has many roles 

une table de jointure à l'aide entre les rôles & utilisateurs de sorte qu'un utilisateur pourrait être un enseignant & admin, ou le professeur d'étudiant &.

rôles peuvent être quelque chose d'aussi simple que

role = id, role name, 

ou d'un système d'autorisation de style de la matrice comme la table des utilisateurs de MySQL

role = id, name, can_write, can_read, etc...