Discussion :

[FloFlo12]

Bonjour,

voilà j'aurais une question au sujet de l'emplacement d'où créer les connexions windows sur SQLserver 2005.
en tant que dba je trouve ça plus simple et d'une meilleure maintenance de les créer directement dans "moteur/sécurité/connexion". Mais j'ai remarqué que certains développeurs qui ont les accès crées les connexions directement dans "moteur/bdd/sécurité/utilisateurs".

en recherchant sur google je n'ai pas trouver de réponse pour connaître la différence ... donc si vous pouviez éclairer ma lanterne.

merci d'avance

[mikedavem]

Bonjour,

Il y a une différence majeure.

moteur/sécurité/connexion --> Vous créez des connexions ou login pour vous connecter au serveur sql.

moteur/bdd/sécurité/utilisateurs --> Ce sont les utilisateurs de la base de données mappés à vos connexions.


++

[FloFlo12]

merci pour votre réponse mais lorsque la connexion est crée directement au niveau du moteur (moteur/sécurité/connexion ) il est alors possible d'y mapper la ou les bdd voulue. Alors que si elle est créée au niveau de la bdd, il faudra recréer la connexion dans les autres bdd aussi ...

[seminoque]

D'après ta réponse, j'ai l'impression que tu confonds connexion et utilisateur.

Comme l'a écrit mikedavem, une connexion permet de se connecter à SQL Server, alors qu'un utilisateur permet de se connecter à une base de données. Les deux doivent être liés (cas théorique : si une connexion n'est associée à aucun utilisateur, on a le droit d'accéder à SQL Server mais on ne peut faire aucune requête dans aucune base).

Chaque base de données possède une table sysusers qui contient ses utilisateurs, alors que les connexions se trouvent à un seul endroit, dans la table syslogins de la base master.

Quand on créée une connexion depuis moteur/sécurité/connexion et qu'on l'associe à plusieurs bases, SQL Server crée un utilisateur dans chacune d'entre elle.

Lorsqu'on crée un utilisateur dans une base depuis moteur/bdd/sécurité/utilisateurs on l'associe à une et une seule connexion.

En espérant que ceci répond à tes questions.
________________________________
Seminoque, créateur de
http://www.bingokaz.com

[FloFlo12]

oui effectivement pour moi connexion et utilisateur est similaire.
je travail toujours avec des comptes windows donc qd tu me dit qu'une connexion peut ne pas avoir d'utilisateur et bien dans mon cas ce n'est pas possible.
merci de ta réponse je comprends mieux.

[SQLpro]

une connexion permet de se connecter à SQL Server, alors qu'un utilisateur permet de se connecter à une base de données.

RECTIFICATION : une connexion permet de se connecter à SQL Server, alors qu'un utilisateur permet de naviguer dans une base de données.

oui effectivement pour moi connexion et utilisateur est similaire.
je travail toujours avec des comptes windows donc qd tu me dit qu'une connexion peut ne pas avoir d'utilisateur et bien dans mon cas ce n'est pas possible.

Vous confondez beaucoup de chose et gérer les connexion à SQL Server à travvers des utilisateurs Windows est à mon sens une abération dans le cas d'applications manipulant les données d'une base...

Reprenons depuis le début.

Au niveau OS vous avez des utilisateurs NT qui sont en fait des comptes de connexion SYSTÈME pour qu'une personne physique (ou un service) puisse accéder à des ressources physiques (fichiers, exécutables...).

Au niveau SGBDR SQL Server, vous avec des comptes de connexion au serveur qui peuvent être de deux sortes :
1) un mappage de compte NT
2) un login purement SQL
Ce compte de connexion permet de se connecter au serveur, mais pas de naviguer dans aucune base de données.
A ce niveau les compte de connexion peuvent être dotés de privilèges de niveau serveur (par exemple la création d'une base de données est une opération typiquement de niveau serveur...).

Toujours au niveau de SQL server, vous avez dans chaque base de données des utilisateurs SQL qui sont en fait des profils de navigation dotés de privilèges (autorisation d'exécution de commandes sur des objets).

A un compte de connexion SQL il est important d'associer au moins un utilisateur SQL dans au moins un base de données. Chaque utilisateur SQL d'une base étant différente des autres, sauf cas particulier (public, dbo...).

Maintenant la raison pour laquelle je vous dit qu'utiliser le mode d'authentification Windows pour accéder à une base de données SQL est idiot est simple :
1) ce ne sont pas les utilisateurs (personnes physiques) qui accèdent au serveur de bases de données, mais des applications...
2) en cas de panne de votre système d'authentification Windows, vous ne pourrez plus avoir accès aux serveur SQL...
La question est : demandez à votre patron ce qu'il pense si la police empêchait les pompiers d'accéder au lieu du sinistre ?

La remarque : ne serait-il pas temps de prévoir une petite formation Administration SQL Server ???

A +