A quoi servent les schémas SQL Server?
Je ne suis pas débutant dans l'utilisation de bases de données SQL, et en particulier SQL Server. Cependant, je suis principalement un utilisateur de SQL 2000 et les schémas de 2005+ m'ont toujours embrouillé. Oui, je connais la définition de base d'un schéma, mais à quoi servent-ils vraiment dans un déploiement typique de SQL Server?
J'ai toujours juste utilisé le schéma par défaut. Pourquoi voudrais-je créer des schémas spécialisés? Pourquoi devrais-je assigner 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 schéma de sécurité, il semble que les rôles de base de données remplissent déjà ce rôle. Et l’utiliser comme spécificateur d’espace de noms semble avoir été quelque chose que vous auriez pu faire avec la propriété (dbo versus utilisateur, etc.).
Je suppose que je veux en venir au fait que font les schémas que vous ne pourriez pas faire avec les propriétaires et les rôles? Quels sont leurs avantages spécifiques?
Les schémas regroupent logiquement les tables, les procédures et les vues. Tous les objets liés aux employés dans le schéma employee, etc.
Vous pouvez également accorder des autorisations à un seul schéma afin que les utilisateurs ne puissent voir que le schéma auquel ils ont accès et rien d'autre.
Tout comme l'espace de noms des codes C #.
Ils peuvent également fournir une sorte de protection contre les collisions de noms pour les données de plug-in. Par exemple, la nouvelle fonctionnalité de capture de données modifié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 à s'inquiéter d'un conflit de nom 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 masquer les noms des tables réelles.
Je sais que c’est un vieux fil de discussion, mais j’ai moi-même étudié les schémas et je pense que ce qui suit pourrait être un autre bon candidat pour l’utilisation du schéma:
Dans un entrepôt de données, avec des données provenant de sources différentes, vous pouvez utiliser un schéma différent pour chaque source, puis par ex. contrôler l'accès en fonction des schémas. Evite également les éventuelles collisions de nommage entre les différentes sources, comme le disait une autre affiche.
Si vous gardez votre schéma discret, vous pouvez alors faire évoluer une application en déployant un schéma donné sur un nouveau serveur de base de données. (Cela suppose que vous avez une application ou un système suffisamment volumineux pour avoir des fonctionnalités distinctes).
Un exemple, considérons un système qui effectue la journalisation. Toutes les tables de journalisation et les SP sont dans le schéma [logging]. La journalisation est un bon exemple car il est rare (voire jamais) que d'autres fonctionnalités du système chevauchent (se joignent à) des objets du schéma de journalisation.
Astuce pour utiliser cette technique: utilisez 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.
J'ai tendance à être d'accord avec Brent sur celui-ci ... voyez 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 au K(eep) I(t) S(imple) S(tupid) règle.
Dans un atelier Oracle où j'ai travaillé pendant de nombreuses années, les schémas ont été utilisés pour encapsuler des procédures (et des packages) qui s'appliquaient à différentes applications frontales. Un schéma 'API' différent pour chaque application était souvent logique car les cas d'utilisation, les utilisateurs et les exigences système étaient très différents. Par exemple, l'un des schémas 'API' concernait une application de développement/configuration destinée uniquement aux développeurs. Un autre schéma "API" permettait d'accéder aux données du client via des vues et des procédures (recherches). Un autre code encapsulé dans un schéma 'API' utilisé pour synchroniser les données de développement/configuration et les données client avec une application disposant de sa propre base de données. Certains de ces schémas 'API', sous les couvertures, partagent toujours des procédures et des fonctions communes (via d'autres schémas 'COMMUNES') là où cela a du sens.
Je dirai que ne pas avoir de schéma n'est probablement pas la fin du monde, bien que cela puisse être très utile. En réalité, c’est le manque de packages dans SQL Server qui me pose vraiment problème, mais c’est un sujet différent.
Je ne vois pas l'avantage de créer un alias pour les utilisateurs liés à Schemas. Voici pourquoi ....
La plupart des gens connectent initialement leurs comptes d’utilisateur à des bases de données via des rôles. Dès que vous affectez un utilisateur à l’administrateur système, ou au rôle de base de données db_owner, quel que soit son format, ce compte a un alias sur le compte utilisateur "dbo" ou a une autorisations sur une base de données. Une fois que cela se produit, quelle que soit la manière dont vous vous affectez à 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 à l'objet que vous avez créé sous votre utilisateur et votre schéma. C'est un peu inutile ..... et juste un espace de noms et confond la propriété réelle sur ces objets. Son design médiocre si vous me le demandez .... quel que soit son concepteur.
Ce qu’ils auraient dû faire est de créer des "groupes", de jeter des schémas et des rôles et de vous permettre simplement de hiérarchiser des groupes de groupes selon la combinaison de votre choix, puis, à chaque niveau, d'indiquer au système si les autorisations sont héritées, refusées ou écrasées par coutume. les uns. Cela aurait été tellement plus intuitif et aurait permis aux administrateurs de bases de données de mieux contrôler l'identité des véritables propriétaires de ces objets. À l’heure actuelle, c’est implicite dans la plupart des cas, l’utilisateur dbo par défaut de SQL Server dispose de ces droits, mais pas de l’utilisateur.
Je pense que les schémas ressemblent à beaucoup de nouvelles fonctionnalités (que ce soit pour SQL Server ou tout autre outil logiciel). Vous devez évaluer avec soin si l'avantage de l'ajouter à votre kit de développement compense la perte de simplicité de conception et de mise en œuvre.
Il me semble que les schémas sont à peu près équivalents aux espaces de noms facultatifs. Si vous vous trouvez dans une situation où les noms d'objet 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 être traités en premier lieu à un niveau plus fondamental.)
Le problème peut être que, s’il existe, certains développeurs commenceront à l’utiliser avec désinvolture pour un bénéfice à court terme; et une fois dedans, cela peut devenir du kudzu.
Dans SQL Server 2000, les objets créés étaient liés à cet utilisateur particulier. Par exemple, si un utilisateur, disons que Sam crée un objet, par exemple, Employees, cette table apparaîtra ainsi: Sam.Employees. Qu'en est-il si Sam quitte l'entreprise ou déménage dans un autre secteur d'activité? Dès que vous supprimez l'utilisateur Sam, qu'adviendrait-il de la table Sam.Employees? Probablement, vous devrez d'abord modifier la propriété de Sam.Employees en dbo.Employess. Schema fournit une solution pour surmonter ce problème. Sam peut créer tout son objet dans un schéma tel que Emp_Schema. Maintenant, s’il crée un objet Employees dans Emp_Schema, cet objet sera appelé Emp_Schema.Employees. Même si le compte utilisateur Sam doit être supprimé, le schéma ne serait pas affecté.
développement - chacun de nos développeurs a son propre schéma en tant que bac à sable pour jouer.
Voici un bon exemple d'implémentation de l'utilisation de schémas avec SQL Server. Nous avions plusieurs applications ms-access. Nous voulions convertir ceux-ci en un portail d'applications ASP.NET. Chaque application ms-access est écrite en tant qu'application pour ce portail. Chaque application ms-access a ses propres tables de base de données. Certains d'entre eux sont liés, nous les plaçons dans le schéma dbo commun de SQL Server. Le reste obtient ses propres schémas. De cette façon, si nous voulons savoir quelles tables appartiennent à une application sur le portail d'applications ASP.NET, il est facile de naviguer, de visualiser et de gérer celle-ci.