Existe-t-il des différences entre Owned Schemaset Role Members?
D'après ma compréhension, les Role Memberssont obligatoires - l'utilisateur doit avoir au moins une des cases à cocher sous Role Memberscochée.
Cependant, ce Owned Schemasn'est pas obligatoire. Cela me fait vraiment me demander pourquoi il y a un besoin d'y avoir Owned Schemas.
Réponses:
Pommes et oranges. Les rôles sont des rôles et les schémas sont des schémas. Le fait qu'il existe un rôle appelé db_accessadminet également un schéma appelé db_accessadminne signifie pas qu'un rôle est un schéma ni qu'un schéma est un rôle. Les rôles sont des conteneurs d'appartenance de sécurité, un principal est membre d'un rôle. Les schémas contiennent des objets liés au schéma de base de données et appartiennent à un principal. Lorsque vous créez un nouvel utilisateur, vous pouvez choisir son schéma par défaut, l'ajouter à certains rôles et lui accorder la propriété des schémas. Bien que les actions sont séparées, les concepteurs de ce dialogue se sentent qu'ils sont en quelque sorte liés à tout ce qui mérite UX immobilier (qui est discutable, mais un tout autre sujet).
Eh bien .. c'est un fil très ancien mais toujours à 2 centimes de moi pour ceux qui vont toujours visiter ici. Ce lien a la meilleure réponse à la requête ci-dessus.
Un extrait du même:
SQL Server est livré avec dix schémas prédéfinis portant les mêmes noms que les utilisateurs et rôles de base de données intégrés. Ceux-ci existent principalement pour des raisons de compatibilité descendante. Vous pouvez supprimer les schémas portant les mêmes noms que les rôles de base de données fixes si vous n'en avez pas besoin.
db_datareaderrôle et le schéma, qui ne sont pas nécessairement lisibles par quelqu'un d'autre. Fonctionnerait bien pour une application qui n'a besoin que d'un accès en lecturedbo, mais doit installer certains proc ou déclencheurs stockés. Bien sûr, cela vous oblige toujours à ajouter manuellement chaque utilisateur au rôle et au schéma.