Conserver l'utilisateur et le profil utilisateur dans des tableaux différents?
J'ai vu dans quelques projets que les développeurs préfèrent conserver les informations utilisateur essentielles dans une table (e-mail/connexion, hachage du mot de passe, nom d'écran) et le reste du profil utilisateur non essentiel dans une autre (date de création, pays, etc.). Par non essentiel, je veux dire que ces données ne sont nécessaires qu'occasionnellement. L'avantage évident est que si vous utilisez ORM, interroger moins de champs est évidemment bon. Mais alors vous pouvez avoir deux entités mappées sur la même table et cela vous évitera d'interroger des choses dont vous n'avez pas besoin (tout en étant plus pratique). Quelqu'un connaît-il un autre avantage à conserver ces choses dans deux tableaux?
Cela dépend de la taille et des exigences de votre projet.
Je peux voir une façon dont les données sur les utilisateurs peuvent être divisées en deux ensembles, avec des objectifs différents et donc des exigences:
- Données d'identité: nom d'utilisateur, hachage du mot de passe, adresse e-mail, dernière heure de connexion, etc.
- Données de profil utilisateur, qui incluent les préférences des utilisateurs, la dernière activité, les mises à jour de statut, etc.
Notez qu'il existe certains attributs concernant l'utilisateur qui peuvent appartenir à l'une ou l'autre catégorie (par exemple la date de naissance de l'utilisateur). La différence entre ces deux ensembles est cependant que le premier est étroitement contrôlé et que ce n'est qu'à travers certains workflows qu'il peut être modifié. Par exemple, la modification d'un mot de passe peut nécessiter la fourniture d'un mot de passe existant, la modification de l'e-mail peut nécessiter une vérification de l'e-mail, et il serait utilisé dans le cas où l'utilisateur oublie le mot de passe.
Les préférences ne nécessitent pas de telles listes de contrôle d'accès et pourraient théoriquement être modifiées par l'utilisateur ou une autre application tant que l'utilisateur y consent. Les enjeux sont faibles si une application malveillante ou due à un bogue corrompt les données ou tente de les modifier (en supposant que d'autres mesures de sécurité soient prises.) Cependant, il serait généralement désastreux si l'un des nom d'utilisateur, mot de passe ou e-mail pouvait être modifié. car ils peuvent être utilisés pour assumer l'identité de l'utilisateur ou refuser le service ou entraîner des frais de support, etc. pour l'administrateur.
Ainsi, les données sont généralement stockées dans deux types de systèmes:
- Les données d'identité iront généralement dans un répertoire ou une solution IAM.
- Les données de préférence se retrouveront dans une base de données.
Cela dit, dans la pratique, les gens violeront ces règles et utiliseront l'un ou l'autre (par exemple, le serveur SQL derrière le fournisseur d'adhésion ASP.NET).
À mesure que les données d'identité deviennent plus grandes ou que l'organisation qui les utilise augmente, différents types de problèmes se glissent. Par exemple, dans le cas d'un répertoire, il tentera de répliquer les modifications de mot de passe immédiatement sur tous les serveurs dans un environnement multiserveur. Cependant, la préférence de l'utilisateur ne nécessite qu'une cohérence éventuelle. (Pour info: les deux sont des optimisations différentes du théorème CAPS.)
Enfin, les répertoires (en particulier les répertoires en ligne/cloud) émettront également des jetons d'accès pour d'autres ressources en utilisant des protocoles tels que OAUTH (par exemple, pensez à Facebook, Google, Microsoft Account, ADFS), tandis qu'une base de données n'a pas un tel besoin. Une base de données prendra en charge des jointures et une structure de requête assez complexes, dont le répertoire n'a pas besoin.
Pour plus de détails, quelques recherches sur le répertoire d'identité par rapport à la base de données seraient utiles.
Il se résume finalement à ce que vos scénarios sont et devraient être à l'avenir, y compris l'intégration avec des tiers (et ce qu'ils utilisent). Si c'est un projet bien contenu et que vous êtes sûr que vous pouvez sécuriser les données d'identité de l'utilisateur et vous authentifier correctement, vous pouvez opter pour la base de données. Sinon, il pourrait être utile d'étudier un répertoire d'identité.
Si vous optez pour la DB, IMO, l'utilisation d'une DB contre deux reviendrait finalement au contrôle d'accès, à la fois pour les utilisateurs et les applications.
Il y a au moins trois cas où il est souhaitable d'avoir une table personne pour les attributs de base et une deuxième table pour les autres attributs avec une relation un-à-un:
- données BLOB comme une image. Une table distincte permet de stocker les données séparément pour des raisons de performances, par exemple dans un espace table séparé.
- Des données qui ne s'appliquent pas à tout le monde ou qui ne s'appliquent qu'à une personne jouant un certain rôle. Considérez-le comme des colonnes qui seraient nulles sur de nombreuses lignes si elles faisaient partie de la table principale. Dans la base de données d'une clinique, vous pouvez avoir une table personne, une table patient et une table medic, dans le premier, vous auriez des attributs de base, dans le second, uniquement des attributs pertinents lorsque la personne est un patient comme une couverture d'assurance, dans le troisième tableau (lorsque la personne est un médecin), vous pourriez avoir la spécialité médicale et d'autres données qui ne s'applique qu'au personnel médical. De toute évidence, un médecin peut être un patient.
- ne table qui matérialise une relation avec une entité dans un système distant. Dans ce cas, la table établit une équivalence entre des identifiants uniques dans une base de données distincte pour des raisons d'interopérabilité.
Je pense que le cas que vous exposez s'inscrit dans le deuxième cas.
Ma principale raison de les garder séparés est d'essayer d'éviter ce qui est connu dans la programmation orientée objet en tant que "classe divine". Les ORM associent les tables et les champs aux classes et aux attributs, de sorte qu'il devient également pertinent au niveau SQL (même sans ORM, un principe similaire est généralement en jeu).
La classe Utilisateur (et par association la table utilisateur) est souvent la table qui devient la classe divine avec des centaines d'attributs/champs, des dizaines ou des centaines de méthodes et une définition de classe (pour les méthodes) de plus de 1000 lignes. J'ai tout vu. Plus d'une fois.
La séparation de l'utilisateur tente donc de résoudre ce problème. Il peut y avoir une personne, un utilisateur, un compte et la séparation des préoccupations peut sembler un peu artificielle, mais il s'agit d'essayer d'éviter la complexité et de s'assurer que chaque objet ne concerne qu'un aspect des données.