À quoi servent les schémas SQL Server?

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?

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.

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 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.

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.

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.

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).

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.

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.

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.

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é.

développement - chacun de nos développeurs obtient 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 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.