Quelles sont les meilleures pratiques d'utilisation des schémas dans SQL Server?

Je comprends les capacités des schémas SQL Server, mais quelles sont les meilleures pratiques? Bien sûr, ils offrent une autre couche de sécurité et fournissent un regroupement logique des objets de base de données dans la base de données, mais qu'est-ce qui est typique là-bas? D'après mon expérience, je ne vois pas souvent de nombreux schémas personnalisés utilisés. Est-ce typique? Est-ce le scénario le moins fréquent où des schémas personnalisés devraient être utilisés?

Nous les utilisons

• pour séparer les autorisations par client (par exemple, nous avons des schémas de bureau, WebGUI, etc.)
• pour le regroupement logique, par exemple (schémas de données et de transfert pour nos tables).

Observations utiles et pratiques après le livre blanc mentionné par Marian:

• GRANT sur le schéma: plus d'autorisations par objet. Donc, un nouveau proc dans le schéma WebGUI a automatiquement les autorisations du schéma
• Jolis regroupements dans SSMS Object Explorer
• OBJECT_SCHEMA_NAME
• Vous êtes obligé de qualifier les noms d'objets (ce qui est la meilleure pratique)

Je pense qu'une réponse peut être trouvée dans cet article MSDN: SQL Server Best Practices - Implementation of Database Object Schemas .

Citation: "Ce livre blanc examine les possibilités d’amélioration de l’administration de la sécurité d’une base de données utilisateur et décrit certaines des meilleures pratiques concernant l’utilisation de schémas pour gérer les objets de base de données dans les bases de données de développement et de production. Plus précisément, il aborde trois scénarios réels:

• Protection des objets de base de données contre les modifications par les utilisateurs à l'insu du propriétaire de la base de données
• Empêcher les objets de base de base de données, en particulier les bases de données des éditeurs de logiciels indépendants (ISV), d'un accès utilisateur ad hoc ou incorrect conduisant à de mauvaises performances des applications
• Rassembler des groupes d'objets connexes (entités logiques) au sein d'une même base de données physique pour réduire la surcharge administrative de la base de données physique ".

J'utilise en particulier la troisième partie - relier un groupe d'objets ensemble en fonction de leur signification logique - différents schémas appartenant à différents projets au sein d'une même base de données.

Vous voudrez peut-être consulter certains des textes fondamentaux à ce sujet pour répondre à certaines de vos questions. Les documents sur le modèle de base de données relationnelle d' EF Codd et CJ Date abordent de nombreuses questions courantes liées à la conception, aux performances, à la sécurité, à la conception de schémas optimaux, etc. ORACLE, SQL Server (Microsoft et Sybase), Ingres, MySQL et tous les autres ensembles de solutions de bases de données relationnelles disponibles.