Discussion :

[cestpasmoinonplus]

Encore cestpasmoi
Toujours à donf sur SQL Server...
Je ne sais pas si c'est moi qui ne voit rien, mais en tout cas, je n'ai rien trouvé répondant à ma question :

J'utilise un seul USER avec lequel une quinzaine d'utilisateur se connectent sur ma base.
Je sais que ce n'est sûrement pas top, mais est-ce que cela pose réellement des soucis de performance ?
Si tous les utilisateurs ont le même "niveau de besoin", cela a t-il un sens de créer un USER par utilisateur ?
Comme d'hab, je vous remercie 1024 fois (pitié, pas celle-là) pour vos avis ou critiques, ça ne mange pas de pain

[janlouk]

J'ignore pour les performances, mais perso si tu n'en as que 15, j'en ferais un pour chacun.

Cela permettrait de suivre l'activité de chacun en cas de problèmes, surtout s'ils ont des privilèges d'écritures.

[cestpasmoinonplus]

Je suis d'accord avec toi. Rien que pour ça, je pense que je devrais le faire.
Mais je me pose surtout la question sur les performances dans le sens où : Est-ce que cela bouchonne plus si tout ce monde utilise le même USER ID.

[StringBuilder]

J'ai envie de répondre "non, au contraire".

Le cache des plans d'exécution se fait session par session.

Si tu codes proprement ton programme (ouverture de la connexion à la base le plus tard possible, et fermeture de la connexion à la base le plus tôt possible) alors tu vas exploiter le pooling de connexion.
=> Les 15 utilisateurs vont peut-être se partager 2 ou 3 sessions maximum, puisque utilisant les mêmes informations de connexion, ils vont réutiliser les session déjà dans le pool.

Ainsi, un utilisateur va bénéficier de plans d'exécution de requêtes qui ont été calculées pour un autre utilisateur.
Et même, si les paramètres sont les mêmes, le nouvel utilisateur pourra même bénéficier des resultsets déjà en cache.

Bref, aucun problème, au contraire. D'ailleurs, les sites web utilisent généralement un unique utilisateur pour toute l'application, et les quelques milliers d'utilisateurs connectés en même temps.
=> En effet, on peut parfaitement ouvrir plusieurs sessions en // sur un SGBD avec le même identifiant, et cela n'a aucun impact négatif sur les performances.

Bref, multiplier les comptes, ça n'a que deux intérêt :
- Avoir une meilleure traçabilité
- Pouvoir affiner les droits d'accès (même si ça sert pas forcément à grand chose puisqu'il est rare que les applications laissent les utilisateurs écrire leurs propres requêtes SQL)

Aussi, cela permet dans les procédure stockées par exemple d'utiliser "CURRENT_USER" comme filtre "en dur" dans les requêtes, afin d'appliquer des droits sur les lignes.

Par exemple :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
create procedure dbo.GetCompanyFromId
(
	@company_id int
)
as
begin
	select distinct c.id, c.code, c.[name], c.[address], c.complement, c.postal_code, c.city, c.country, c.siret, c.phone, c.fax, c.email, c.inactive, c.payer, c.[type]
	from dbo.company c
	inner join dbo.[role] r on (r.company_id is null or r.company_id = c.id)
	inner join dbo.person p on p.id = r.person_id
	where p.[login] = CURRENT_USER
	and c.id = @company_id
	and c.inactive = 0;
end;
go

=> Même si un utilisateur trouve un moyen d'injecter des paramètres, il ne peut pas se faire passer pour un autre utilisateur, et n'aura accès qu'aux données auxquelles il a accès.

Alors que l'équivalent "user partagé" :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
create procedure dbo.GetCompanyFromId
(
	@company_id int,
        @login varchar(30)
)
as
begin
	select distinct c.id, c.code, c.[name], c.[address], c.complement, c.postal_code, c.city, c.country, c.siret, c.phone, c.fax, c.email, c.inactive, c.payer, c.[type]
	from dbo.company c
	inner join dbo.[role] r on (r.company_id is null or r.company_id = c.id)
	inner join dbo.person p on p.id = r.person_id
	where p.[login] = @login
	and c.id = @company_id
	and c.inactive = 0;
end;
go

=> Si l'utilisateur trouve le moyen de passer un autre @login que le sien, il peut récupérer les informations de sociétés auxquelles il ne devrait pas avoir accès.

[cestpasmoinonplus]

Merci beaucoup StringBuilder
Voilà qui semble répondre à ma question.

[SQLpro]

au niveau des performances pas de différence, mais au niveau sécurité, il est préférable que chaque personnes de l'entreprise soit associé à un seul utilisateur SQL qui lui est propre. En faisant cela tu te facilitera la vie pour tout ce qui est tracabilité et notamment RGPD !

A +