À quoi servent les schémas de SQL Server ?

Question

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 typique de SQL Server ?

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

EDIT : Pour clarifier, je pense que je cherche 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 euh hum rôle. Et l'utiliser comme un séparateur d'espace de noms semble être quelque chose que vous auriez pu faire avec la propriété (dbo contre utilisateur, etc..).

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

Answer 1

Pour regrouper logiquement des tables, des procédures, des vues, tous les objets liés aux employés dans le schéma des employés, etc, etc.

Vous pouvez également donner des autorisations pour un seul schéma afin que les utilisateurs ne puissent voir que le schéma auquel ils ont accès et rien d'autre.

Answer 2

Tout comme le Namespace des codes C#.

Answer 3

Ils peuvent également fournir une sorte de protection contre les collisions de noms pour les données des plugins. Par exemple, la nouvelle fonction Change Data Capture de SQL Server 2008 place les tables qu'elle utilise dans un schéma cdc distinct. Ainsi, 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.

Answer 4

Je sais que c'est un vieux sujet, mais je viens de me pencher sur les schémas et je pense que ce qui suit pourrait être un autre bon candidat pour l'utilisation de schémas :

Dans un entrepôt de données, 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 en fonction des schémas. Cela permet également d'éviter les éventuelles collisions de noms entre les différentes sources, comme l'a répondu une autre personne ci-dessus.

Answer 5

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

Prenons l'exemple d'un système qui effectue la journalisation. Toutes les tables de journalisation et les PS 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 (c'est-à-dire rejoignent) 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 du schéma sur un nouveau serveur et modifiez votre chaîne de connexion lorsque vous avez besoin d'évoluer.