Utilisateurs dans le serveur de base de données ou les tables de base de données

Question

Je suis tombé sur un problème intéressant concernant la conception d'applications de serveur client.

Nous avons cette application de gestion basée sur un navigateur où de nombreux utilisateurs utilisent le système. Nous avons donc un module de gestion des utilisateurs à l'intérieur de cette application.

J'ai toujours pensé avoir une table d'utilisateur dans la base de données pour garder tous les détails de connexion était assez bon.

Cependant, un développeur senior a déclaré que la gestion des utilisateurs devrait être effectuée dans la couche serveur de la base de données si elle n'est pas alors mal conçue. Ce qu'il voulait dire, c'est que si un utilisateur veut utiliser l'application, un utilisateur doit également être créé dans la table utilisateur ET dans le serveur de base de données en tant que compte utilisateur. Donc, si j'ai 50 utilisateurs qui utilisent mes applications, alors je devrais avoir 50 connexions utilisateur de serveur de base de données.

Je pense personnellement qu'avoir un seul compte utilisateur dans le serveur de base de données pour cette base de données était suffisant. Accordez simplement à cet utilisateur les privilèges autorisés pour faire fonctionner tout le besoin d'opération nécessaire par l'application. Les utilisateurs qui interagissent avec l'application doivent avoir leurs comptes d'utilisateurs créés et gérés dans la table de base de données car ils sont plus liés à la couche d'application. Je ne vois pas et je suis d'accord qu'il est nécessaire de créer un compte utilisateur de serveur de base de données pour chaque utilisateur créé pour l'application dans la table utilisateur.

Un utilisateur de serveur de base de données unique devrait suffire à gérer toutes les requêtes envoyées par l'application.

Vraiment l'espoir d'entendre quelques suggestions/opinions et si quelque chose me manque? problèmes de performance ou de sécurité?

Merci beaucoup.

Answer 1

Non, les utilisateurs sont autorisés à utiliser l'application; l'application est autorisée à accéder à la base de données. Vous n'avez pas besoin des deux.

Vous pouvez avoir différentes autorisations d'accès dans la base de données (par exemple, les utilisateurs ne peuvent pas supprimer ou supprimer des tables, les administrateurs peuvent faire n'importe quoi). Dans ce cas, il est courant d'avoir une conception de rôle de groupe d'utilisateurs dans laquelle les utilisateurs sont affectés à des groupes, et chaque groupe a ses propres autorisations.

Answer 2

Votre "développeur senior" se trompe tristement. Je ne suis pas sûr de savoir comment quelqu'un qui serait qualifié de «senior» dirait que 1 utilisateur de l'application == 1 utilisateur db. Comme indiqué précédemment, l'application ne sera pas mise à l'échelle (à bien des égards). Si la base de données est quelque chose comme Oracle suggère-t-il que tout utilisateur d'une grande application Web devrait être considéré comme un utilisateur db aussi bien en termes de coûts de licence? Qu'en est-il de la gestion des utilisateurs? Je ne sais pas quelle base de données vous utilisez, mais un seul utilisateur qui est responsable de l'accès à la base de données via le serveur d'applications est suffisant dans la plupart des cas. Les utilisateurs d'applications peuvent être stockés dans la base de données, dans LDAP, etc.

Vous ne voulez pas le cauchemar de la maintenance de 1 utilisateur d'application = 1 utilisateur db. La personne âgée devrait avoir honte de suggérer une telle chose.

Answer 3

Je ne vois aucun point valide dans la création de comptes d'utilisateurs dans la base de données pour les utilisateurs de l'application.

Answer 4

Il y a un point que je peux penser en faveur d'exiger aux utilisateurs des comptes d'utilisateur de base de données. Si vous utilisez l'approche d'une table utilisateur personnalisée distincte, votre application doit avoir une chaîne de connexion intégrée afin de se connecter à la base de données pour authentifier l'utilisateur.Si votre application est piratée, le pirate dispose des informations d'identification de la base de données pour faire ce qu'il veut.

Toutefois, si l'utilisateur qui se connecte dispose d'un compte de base de données, votre application peut simplement utiliser les informations d'identification de la base de données de cet utilisateur. Il n'est pas nécessaire de stocker une chaîne de connexion à la base de données dans votre application.