À quoi servent les schémas SQL Server?
Je ne suis pas un débutant à l'utilisation des bases de données SQL, et en particulier SQL Server. Cependant, J'ai été principalement un gars de SQL 2000 et j'ai toujours été confus par des schémas en 2005+. Oui, je connais la définition de base d'un schéma, mais à quoi servent-ils réellement dans un déploiement SQL Server typique?
j'ai toujours utilisé le schéma par défaut. Pourquoi voudrais-je créer des schémas spécialisés? Pourquoi j'attribuerais les schémas intégrés?
EDIT: Pour clarifier, je suppose que je cherche les avantages des schémas. Si vous allez seulement l'utiliser comme schéma de sécurité, il semble que les rôles de base de données ont déjà rempli cela.. er.. la messagerie unifiée.. 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 user, etc..).
je suppose que ce que je veux dire c'est, qu'est-ce que les schémas font que vous ne pouviez pas faire avec les propriétaires et les rôles? Quels sont leurs avantages spécifiques?
11 réponses
schèmes groupant logiquement des tables, des procédures, des vues ensemble. Tous les objets liés aux employés dans le schéma employee , etc.
vous pouvez également donner des permissions à 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.
ils peuvent également fournir une sorte de protection de collision de nom pour les données de plugin. Par exemple, la nouvelle fonction de saisie des données de changement dans SQL Server 2008 place les tables qu'il utilise dans un schéma cdc séparé. De cette façon, ils n'ont pas à se soucier d'un conflit de noms entre une table CDC et une vraie table utilisée dans la base de données, et pour cette matière peut délibérément suivre les noms des vraies tables.
je sais que c'est un vieux fil, mais je viens de regarder dans les schémas moi-même et pense que ce qui suit pourrait être un autre bon candidat pour l'utilisation de 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, et ensuite par exemple contrôler l'accès basé sur les schémas. Évite également les possibles collisions de noms entre les différentes sources, comme un autre poster a répondu ci-dessus.
si vous gardez votre schéma discret, alors vous pouvez dimensionner une application en déployant un schéma donné sur un nouveau serveur DB. (Cela suppose que vous avez une application ou un système qui est assez grand pour avoir des fonctionnalités distinctes).
un exemple, considérez un système qui effectue la journalisation. Toutes les tables de journalisation et les SPs sont dans le schéma [de journalisation]. La journalisation est un bon exemple parce qu'il est rare (si jamais) que d'autres fonctionnalités dans le système de chevauchement (c'est-à joindre à) objets dans le schéma de journalisation.
un conseil pour utiliser cette technique -- avoir une chaîne de connexion différente pour chaque schéma dans votre application / système. Ensuite, vous déployez les éléments de schéma sur un nouveau serveur et changez votre chaîne de connexion lorsque vous avez besoin de passer à l'échelle.
J'ai tendance à être d'accord avec Brent sur ce point... 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 dans des cas très précis. Rend les choses en désordre. Ne pas utiliser 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 d'aliasing des utilisateurs liés à des schémas. Voici pourquoi....
la plupart des gens connectent leurs comptes d'utilisateur à des bases de données via des rôles initialement, dès que vous assignez un utilisateur au sysadmin, ou le rôle de base de données db_owner, sous n'importe quelle forme, ce compte est soit aliasé au compte d'utilisateur" dbo", ou a des permissions complètes sur une base de données. Une fois que cela se produit, peu importe comment vous vous assignez à un schéma au-delà de votre schéma par défaut (qui a le même nom comme votre compte d'utilisateur), ces droits dbo sont attribués à l'objet que vous créez sous votre Utilisateur et schéma. Son un peu inutile.....et juste un espace-nom et confond la propriété réelle sur ces objets. Son mauvais design, si vous voulez mon avis....qui l'a conçu.
ce qu'ils auraient dû faire est de créer des "groupes", et jeter les schémas et le rôle et juste vous permettre de niveau des groupes de groupes dans n'importe quelle combinaison que vous aimez, puis à chaque niveau dire au système Si les permissions sont hérité, nié, ou réécrit avec des coutumes. Cela aurait été tellement plus intuitif et a permis aux DBA de mieux contrôler qui sont les vrais propriétaires sur ces objets. À l'heure actuelle son implicite dans la plupart des cas L'utilisateur dbo par défaut SQL Server a ces droits....pas l'utilisateur.
dans une boutique ORACLE où j'ai travaillé pendant de nombreuses années, des schémas ont été utilisés pour encapsuler des procédures (et des paquets) qui s'appliquaient à différentes applications frontales. Un schéma différent d' " API " pour chaque application avait souvent du sens, car les cas d'utilisation, les utilisateurs et les exigences du système étaient très différents. Par exemple, un schéma d '" API " était destiné à une application de développement/configuration qui ne devait être utilisée que par les développeurs. Un autre schéma "API" était pour accéder aux données du client via des vues et des procédures (rechercher.) Un autre schéma' API ' Code encapsulé qui a été utilisé pour synchroniser le développement / la configuration et les données du client avec une application qui avait sa propre base de données. Certains de ces schémas "API", sous les couvertures, partageraient encore des procédures et des fonctions communes avec d'autres (via d'autres schémas "communs") où cela aurait du sens.
je dirai que ne pas avoir de schéma n'est probablement pas la fin du monde, bien qu'il puisse être très utile. Vraiment, c'est le manque de paquets dans SQL Server qui crée vraiment des problèmes dans mon esprit... mais c'est un autre sujet.
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 à des espaces de noms optionnels. Si vous êtes dans une situation où les noms d'objets entrent en collision et la granularité des permissions n'est pas assez bonne, voici un outil. (J'avais être enclin à dire qu'il pourrait y avoir des questions de conception qui devraient être traitées à un niveau plus fondamental d'abord.)
le problème peut être que, s'il est là, certains développeurs vont commencer à l'utiliser de manière fortuite pour le bénéfice à court terme; et une fois qu'il est là, 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 ressemblerait à: Sam.Employé. Quel si Sam quitte la compnay ou déménage dans un autre secteur. Dès que vous supprimez L'utilisateur Sam, ce qui arriverait à Sam.La table des employés? Probablement, vous devriez changer la propriété D'abord de Sam.Employés à 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 employés dans Emp_Schema alors l'objet serait dénommé Emp_Schema.Employé. Même si le compte D'utilisateur Sam doit être supprimé, le schéma ne seraient pas touchés.
développement-chacun de nos devs obtenir leur propre schéma comme un bac à sable pour jouer.