Schéma, propriétaire des objets en MS SQL

Question

Par défaut, les objets (tables, procédures stockées, etc.) sont configurés avec le propriétaire / schéma dbo (je pense que ms sq 2000 l’appelle propriétaire, alors que ms sql 2005 l’appelle schéma)

Le propriétaire / schéma est vraiment un rôle ou un utilisateur dans la base de données. J'ai toujours laissé la valeur par défaut de dbo, mais j'ai récemment vu quelques exemples dans des livres de formation Microsoft où certains de leurs tableaux & amp; les procédures stockées avaient différents propriétaires / schémas. Quand est-ce avantageux de faire cela et pourquoi?

Answer 1

L'utilisation de schémas est particulièrement bénéfique lorsque vous avez des problèmes de sécurité.

Si plusieurs applications accèdent à la base de données, vous pouvez ne pas vouloir donner au service de la logistique un accès aux enregistrements de ressources humaines. Vous placez donc toutes vos tables de ressources humaines dans un schéma de ressources humaines et vous n'y autorisez l'accès que pour les utilisateurs dotés du rôle de ressources humaines.

Six mois plus tard, Logistique doit maintenant connaître les comptes de dépenses internes pour pouvoir envoyer toutes ces palettes de stylos bleus aux personnes qui se trouvent au bon endroit. Vous pouvez ensuite créer une procédure stockée qui s'exécute en tant qu'utilisateur autorisé à afficher le schéma hr ainsi que le schéma logistique. Les utilisateurs de la logistique n’ont jamais besoin de savoir ce qui se passe dans les ressources humaines et pourtant ils obtiennent toujours leurs données.

Vous pouvez également utiliser les schémas de la manière suggérée par cfeduke et les utiliser simplement pour regrouper des éléments dans le navigateur d'objets. Si vous faites cela, faites attention car vous risquez de créer Person.Address et Company.Address alors que vous n’avez vraiment besoin que d’un seul dbo.Address (je ne suis pas en train de casser votre exemple, cfeduke, mais de le les tables d'adresses peuvent être identiques ou différentes et que YMMV).

Answer 2

Dans SQL 2000, les schémas étaient équivalents aux utilisateurs de base de données. Dans SQL 2005, chaque schéma est un espace de nom distinct qui existe indépendamment de l'utilisateur de la base de données qui l'a créé.

J'utilise des schémas lorsque je dois créer des fonctionnalités ou des modules qui seront peut-être utilisés ultérieurement dans d'autres projets. Je pourrai ainsi isoler les objets de base de données utilisés par le module.

Answer 3

J'ai utilisé des schémas dans le passé comme des espaces de noms afin que vous puissiez avoir plusieurs entités nommées Address ( [Personne]. [Adresse] , [Société]. [Adresse] ). L’avantage de cela est l’organisation visuelle dans SQL Management Studio. Vous pouvez obtenir la même chose en mettant tout sous un même schéma et en nommant les tables avec un seul identifiant (par exemple, [dbo]. [PersonAddress] ).

Je les ai également utilisées pour le développement entre développeurs avant d'exécuter SQL Server Developer Edition sur toutes nos machines de développement (à l'époque où nous avions une base de données de développement centralisée plus tôt dans ma carrière).

Answer 4

Organisation

Dans un environnement de développement, la copie de production des objets est dbo, mais les développeurs peuvent développer leurs propres schémas. Ensuite, le code peut référencer très simplement la copie de produit ou ses modifications. L'utilisation d'alias peut rendre cette technique encore plus simple.

De plus, une base de données de production peut prendre en charge de nombreux systèmes ou sous-systèmes. Vous pouvez utiliser des schémas distincts pour conserver ces objets groupés.

Answer 5

Cet article explique bien le processus, y compris les modifications apportées de SQL Server 2000 à 2005.