À quoi servent les schémas SQL Server?


188

Je ne suis pas un débutant dans l'utilisation des bases de données SQL, et en particulier de SQL Server. Cependant, j'ai été principalement un gars de SQL 2000 et j'ai toujours été confus par les schémas en 2005+. Oui, je connais la définition de base d'un schéma, mais à quoi servent-ils vraiment dans un déploiement SQL Server classique?

J'ai toujours juste utilisé le schéma par défaut. Pourquoi voudrais-je créer des schémas spécialisés? Pourquoi attribuerais-je l'un des schémas intégrés?

EDIT: Pour clarifier, je suppose que je recherche les avantages des schémas. Si vous ne l'utilisez que comme système de sécurité, il semble que les rôles de base de données remplissent déjà ce rôle .. euh .. euh ... Et l'utiliser comme un spécificateur d'espace de noms semble avoir été quelque chose que vous auriez pu faire avec la propriété (dbo contre utilisateur, etc.).

Je suppose que ce à quoi je veux en venir est, que font les schémas que vous ne pouvez pas faire avec les propriétaires et les rôles? Quels sont leurs avantages spécifiques?

Réponses:


166

Les schémas regroupent logiquement les tables, les procédures et les vues. Tous les objets liés aux employés dans le employeeschéma, etc.

Vous pouvez également accorder des autorisations à un seul schéma, de sorte que les utilisateurs ne puissent voir que le schéma auquel ils ont accès et rien d'autre.


22
La possibilité d'attribuer des autorisations à un schéma en vaut la peine du point de vue de l'administration.
Hakan Winther

9
Ne pourriez-vous pas utiliser une base de données distincte?
sam yi

7
Ce schéma d'autorisation sonne bien sur papier ... mais rarement utilisé correctement. Pour moi, cela ne vaut pas la peine.
sam yi

3
Mais si tel est le cas, ne pourriez-vous pas obtenir la même chose en utilisant des conventions de dénomination? Je ne suggère pas de cas d'utilisation pour cela; c'est, le plus souvent, une addition par soustraction.
sam yi

7
@ Ajedi32, ouais ... avec les schémas, vous pouvez obtenir un seul commit atomique dans un seul journal de transactions et sauvegarder toutes vos données en un seul coup par rapport à deux bases de données qui ne sont pas synchronisées et à lutter contre les transactions distribuées.
Matthew Whited

32

Tout comme l'espace de noms des codes C #.


17
Malheureusement , les schémas et les espaces de noms .NET ne fonctionnent pas très bien ensemble du point de vue ORM (à savoir Entity Framework ). Les tables du MyDatabase.MySchemaschéma ne correspondent pas comme par magie aux classes d'entité dans l' MyProject.MyDatabase.MySchemaespace de noms. Il est également intéressant de noter que tous les .hacks de notation par points ( ) dans les noms de table finiront par des traits de soulignement ( _) dans les noms de classe. Juste de la nourriture pour une pensée malheureuse.
Dan Lugg

2
Bonne analogie pour l'enseignement. Je ne pense pas que cela soit pris à 100% littéralement ... (ces mises en garde semblent mineures dans la pratique)
Samantha Branham

6
Personnellement, je souhaite qu'ils étaient plus comme namespaces .NET, de sorte que l' on pourrait imbriquer un nombre arbitraire de schémas de ( que vous pouvez avec namespaces ) à des fins d' organisation. Cela, et j'aimerais qu'ils cartographient mieux dans EF.
Dan Lugg

Ils ne sont pas comme des espaces de noms dans toutes les langues auxquelles je pense.
Tanveer Badar le

31

Ils peuvent également fournir une sorte de protection contre les collisions de noms pour les données des plugins. Par exemple, la nouvelle fonctionnalité Modifier la capture de données dans SQL Server 2008 place les tables qu'elle utilise dans un schéma cdc distinct. De cette façon, ils n'ont pas à se soucier d'un conflit de dénomination entre une table CDC et une table réelle utilisée dans la base de données, et peuvent d'ailleurs délibérément occulter les noms des tables réelles.


18

Je sais que c'est un vieux thread, mais j'ai juste regardé dans les schémas moi-même et je pense que ce qui suit pourrait être un autre bon candidat pour l'utilisation du schéma:

Dans un Datawarehouse, avec des données provenant de différentes sources, vous pouvez utiliser un schéma différent pour chaque source, puis par exemple contrôler l'accès en fonction des schémas. Évite également les éventuelles collisions de dénomination entre les différentes sources, comme l'a répondu un autre poster ci-dessus.


9

Si vous gardez votre schéma discret, vous pouvez mettre à l'échelle une application en déployant un schéma donné sur un nouveau serveur de base de données. (Cela suppose que vous disposez d'une application ou d'un système suffisamment grand pour avoir des fonctionnalités distinctes).

Prenons l'exemple d'un système qui effectue la journalisation. Toutes les tables de journalisation et SP sont dans le schéma [journalisation]. La journalisation est un bon exemple car il est rare (voire jamais) que d'autres fonctionnalités du système chevauchent (c'est-à-dire se joignent à) les objets du schéma de journalisation.

Un conseil pour utiliser cette technique - ayez une chaîne de connexion différente pour chaque schéma de votre application / système. Ensuite, vous déployez les éléments de schéma sur un nouveau serveur et modifiez votre chaîne de connexion lorsque vous devez effectuer une mise à l'échelle.


8

J'ai tendance à être d'accord avec Brent sur celui-ci ... voir cette discussion ici. http://www.brentozar.com/archive/2010/05/why-use-schemas/

En bref ... les schémas ne sont pas très utiles, sauf pour des cas d'utilisation très spécifiques. Rend les choses en désordre. Ne les utilisez pas si vous pouvez l'aider. Et essayez d'obéir à la règle K (eep) I (t) S (imple) S (tupid).


2
Je ne pense pas que Brent prétend que "les schémas sont mauvais", juste que l'utilisation de schémas non par défaut est bien plus complexe que d'utiliser simplement le schéma par défaut. Le reste de votre résumé est exact.
Joseph Daigle

"Si [les schémas sont] utilisés correctement, ils vous permettent de séparer les autorisations par groupes d'objets." ~ brentozar.com/archive/2010/05/why-use-schemas
LL Learner

7

Je ne vois pas l'avantage de créer des alias pour les utilisateurs liés aux schémas. Voici pourquoi ...

La plupart des gens connectent initialement leurs comptes d'utilisateurs aux bases de données via des rôles. Dès que vous attribuez un utilisateur au sysadmin ou au rôle de base de données db_owner, sous quelque forme que ce soit, ce compte est soit aliasé sur le compte utilisateur "dbo", soit autorisations sur une base de données. Une fois que cela se produit, quelle que soit la façon dont vous vous attribuez à un schéma au-delà de votre schéma par défaut (qui porte le même nom que votre compte d'utilisateur), ces droits dbo sont attribués aux objets que vous créez sous votre utilisateur et votre schéma. C'est un peu inutile ..... et juste un espace de noms et confond la vraie propriété sur ces objets. Sa conception médiocre si vous me demandez ... qui l'a conçue.

Ce qu'ils auraient dû faire est de créer des «groupes», de supprimer les schémas et le rôle et de vous permettre simplement de hiérarchiser des groupes de groupes dans n'importe quelle combinaison que vous souhaitez, puis à chaque niveau d'indiquer au système si les autorisations sont héritées, refusées ou écrasées avec ceux. Cela aurait été tellement plus intuitif et aurait permis aux DBA de mieux contrôler qui sont les vrais propriétaires de ces objets. À l'heure actuelle, il est implicite dans la plupart des cas que l'utilisateur SQL Server par défaut de dbo a ces droits ... pas l'utilisateur.


7

Dans un magasin ORACLE dans lequel j'ai travaillé pendant de nombreuses années, des schémas étaient utilisés pour encapsuler des procédures (et des packages) qui s'appliquaient à différentes applications frontales. Un schéma d'API différent pour chaque application avait souvent du sens car les cas d'utilisation, les utilisateurs et les exigences système étaient très différents. Par exemple, un schéma «API» était destiné à une application de développement / configuration uniquement destinée aux développeurs. Un autre schéma «API» était pour accéder aux données client via des vues et des procédures (recherches). Un autre code encapsulé de schéma 'API' qui a été utilisé pour synchroniser le développement / la configuration et les données client avec une application qui avait sa propre base de données. Certains de ces schémas `` API '', sous les couvertures, partageraient toujours des procédures et des fonctions communes les uns avec les autres (via d'autres

Je dirai que ne pas avoir de schéma n'est probablement pas la fin du monde, même si cela peut être très utile. Vraiment, c'est le manque de packages dans SQL Server qui crée vraiment des problèmes dans mon esprit ... mais c'est un sujet différent.


Avec Oracle, puisque 1 instance = 1 base de données = 1 licence à payer, les gens utilisent des shemas pour éviter de créer une autre base de données et de payer pour une autre licence. Dans SQl Server, 1 serveur peut gérer de nombreuses bases de données.
Patrick Honorez

5

Je pense que les schémas sont comme beaucoup de nouvelles fonctionnalités (que ce soit pour SQL Server ou tout autre outil logiciel). Vous devez évaluer soigneusement si l'avantage de l'ajouter à votre kit de développement compense la perte de simplicité dans la conception et la mise en œuvre.

Il me semble que les schémas sont à peu près équivalents aux espaces de noms facultatifs. Si vous êtes dans une situation où les noms d'objets entrent en collision et que la granularité des autorisations n'est pas assez fine, voici un outil. (Je serais enclin à dire qu'il pourrait y avoir des problèmes de conception qui devraient d'abord être traités à un niveau plus fondamental.)

Le problème peut être que, s'il est là, certains développeurs commenceront à l'utiliser avec désinvolture pour un bénéfice à court terme; et une fois qu'il est là-dedans, il peut devenir kudzu.


3

Dans SQL Server 2000, les objets créés étaient liés à cet utilisateur particulier, comme si un utilisateur, disons Sam, crée un objet, disons Employés, cette table apparaîtrait comme suit: Sam.Employees. Et si Sam quitte l'entreprise ou déménage dans un autre secteur d'activité. Dès que vous supprimez l'utilisateur Sam, qu'advient-il de la table Sam.Employees? Vous devrez probablement d'abord changer la propriété de Sam.Employees en dbo.Employess. Schema fournit une solution pour surmonter ce problème. Sam peut créer tous ses objets dans un schéma tel que Emp_Schema. Désormais, s'il crée un objet Employés dans Emp_Schema, l'objet sera appelé Emp_Schema.Employees. Même si le compte utilisateur Sam doit être supprimé, le schéma ne sera pas affecté.


1
Ce n'est plus vrai depuis qu'il y a eu deux nouvelles versions depuis 2000
Hogan

0

développement - chacun de nos développeurs obtient son propre schéma en tant que bac à sable pour jouer.


30
-1 Il est préférable de donner aux développeurs des copies entières de la base de données pour jouer sur leur propre machine. Sinon, ils ne pourraient modifier en toute sécurité que ce qui se trouve dans leur schéma. Cela complique la promotion à vivre et complique également la séparation des schémas pour d'autres raisons décrites par d'autres réponses.
Stephen Turner

6
Je ne peux pas parler de l'application sur laquelle vous travaillez ... mais votre développement doit refléter le plus possible la production. Avoir des schémas en développement et non en production peut être problématique.
sam yi

0

Voici un bon exemple d'implémentation de l'utilisation de schémas avec SQL Server. Nous avions plusieurs applications ms-access. Nous voulions les convertir en un portail d'application ASP.NET. Chaque application ms-access est écrite en tant qu'application pour ce portail. Chaque application ms-access possède ses propres tables de base de données. Certains d'entre eux sont liés, nous les mettons dans le schéma dbo commun de SQL Server. Le reste a ses propres schémas. De cette façon, si nous voulons savoir quelles tables appartiennent à une application sur le portail d'application ASP.NET qui peut facilement être parcourue, visualisée et maintenue.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.