A 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 toujours été un gars de SQL 2000 et j’ai toujours été dérouté par les 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 atsortingbuer un des schémas intégrés?

EDIT: Pour clarifier, je suppose que je cherche les avantages des schémas. Si vous ne l’utilisez que comme système de sécurité, il semble que les rôles de firebase database aient déjà été remplis. 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 ou utilisateur, etc.).

Je suppose que ce que je veux dire, c’est ce 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 des tableaux, des procédures et des vues ensemble. Tous les objects liés aux employee dans le schéma d’ employee , etc.

Vous pouvez également accorder des permissions à un seul schéma, afin que les utilisateurs puissent uniquement voir le schéma auquel ils ont access 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é Change Data Capture de SQL Server 2008 place les tables utilisées dans un schéma cdc distinct. De cette façon, ils n’ont pas à se soucier d’un conflit de noms entre une table CDC et une table réelle utilisée dans la firebase database, et peuvent même délibérément masquer les noms des tables réelles.

Je sais que c’est un vieux sujet, mais je me suis contenté de regarder 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 contrôler, par exemple, l’access en fonction des schémas. Évite également les éventuelles collisions de nommage entre les différentes sources, comme une autre affiche a répondu ci-dessus.

Si vous conservez votre schéma discret, vous pouvez dimensionner une application en déployant un schéma donné sur un nouveau serveur de firebase database. (Cela suppose que vous ayez une application ou un système suffisamment grand pour avoir des fonctionnalités distinctes).

Un exemple, considérez un système qui effectue la journalisation. Toutes les tables de journalisation et tous les fournisseurs de services se trouvent dans le schéma [de journalisation]. La journalisation est un bon exemple car il est rare (voire jamais) que d’autres fonctionnalités du système se chevauchent (c’est-à-dire qu’elles se joignent à des objects) dans le schéma de consignation.

Une astuce pour utiliser cette technique – avoir 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 dans 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 (impuls) S (tupid).

Je ne vois pas l’avantage à éliminer les utilisateurs liés aux schémas. Voici pourquoi ….

Au départ, la plupart des utilisateurs connectent leurs comptes d’utilisateurs à des bases de données. Dès que vous affectez un utilisateur au rôle sysadmin ou au rôle de firebase database db_owner, sous quelque forme que ce soit, ce compte est associé au compte utilisateur dbo. permissions sur une firebase database. Une fois que cela se produit, peu importe comment 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 atsortingbués aux objects que vous créez sous votre utilisateur et votre schéma. Son un peu inutile ….. et juste un espace de noms et confond la véritable propriété sur ces objects. Sa mauvaise conception si vous me demandez …. qui l’a conçu.

Ce qu’ils auraient dû faire, c’est de créer des “Groupes” et d’exclure des schémas et des rôles et de vous permettre de classer des groupes de groupes dans n’importe quelle combinaison, puis d’indiquer au système si les permissions sont héritées, refusées ou écrasées. ceux Cela aurait été tellement plus intuitif et a permis aux DBA de mieux contrôler qui sont les vrais propriétaires sur ces objects. Actuellement, dans la plupart des cas, l’utilisateur SQL Server par défaut de dbo possède ces droits … pas l’utilisateur.

Dans un magasin ORACLE où je travaillais depuis de nombreuses années, les schémas étaient utilisés pour encapsuler les procédures (et les packages) applicables aux différentes applications frontales. Un schéma d’API différent pour chaque application était souvent utile, car les cas d’utilisation, les utilisateurs et les exigences du système étaient très différents. Par exemple, un schéma “API” était destiné à une application de développement / configuration destinée uniquement aux développeurs. Un autre schéma «API» était destiné à accéder aux données client via des vues et des procédures (recherches). Un autre code encapsulé dans le schéma “API” utilisé pour synchroniser les données de développement / configuration et client avec une application possédant sa propre firebase database. Certains de ces schémas “API”, sous les couvertures, partageraient toujours des procédures et des fonctions communes (via d’autres schémas “COMMON”) là où c’était logique.

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. En réalité, c’est le manque de paquets 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’append à 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 vous trouvez dans une situation où les noms d’object entrent en collision et où la granularité des permissions n’est pas suffisante, voici un outil. (Je serais enclin à dire qu’il pourrait y avoir des problèmes de conception qui devraient être abordés à un niveau plus fondamental en premier.)

Le problème peut être que, s’il existe, certains développeurs commenceront à l’utiliser pour des avantages à court terme; et une fois qu’il est là, il peut devenir kudzu.

Dans SQL Server 2000, les objects créés étaient liés à cet utilisateur particulier, par exemple si un utilisateur, par exemple, crée un object, par exemple, Employees, cette table apparaîtrait comme: 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’arrivera-t-il à la table Sam.Employees? Vous devrez probablement changer d’abord la propriété de Sam.Employees à dbo.Employess. Schema fournit une solution pour résoudre ce problème. Sam peut créer tout son object dans un schéma tel que Emp_Schema. Maintenant, s’il crée un object Employees dans Emp_Schema, l’object sera appelé Emp_Schema.Employees. Même si le compte d’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 y jouer.