Comment l'utilisation de schémas distincts affecte-t-elle les performances de SQL Server 2008?

Je souhaite utiliser des schémas distincts pour des objets ayant des finalités différentes dans notre base de données SQL Server 2008. À l'heure actuelle, nous utilisons une convention de dénomination assez abrutissante pour indiquer le but d'une table ou d'une procédure stockée, et les préfixes signifient que nous devons analyser cinq ou six caractères x avant même de voir le début du nom unique. Je voudrais utiliser des schémas séparés pour les tables qui sont juste utilisées pour piloter l'interface utilisateur (menus, rôles par personne, etc.) et pour celles qui sont des tables de dimension par rapport aux tables de faits, etc.

Ma question est, y aura-t-il des impacts sur les performances de l'utilisation de plusieurs schémas (schémas?) Opposés au bon vieux dbo pour tout?

Il peut y avoir un impact sur les performances de l'optimiseur de requête, même s'il est petit, en fonction de votre style de codage. Si vous référencez une table sans schéma, l'optimiseur doit d'abord essayer d'identifier la table en vérifiant les tables dans le schéma par défaut des utilisateurs (s'il y en a un), puis en utilisant dbo., Puis tout le reste. Si vous référencez explicitement les tables en tant que schema.table, ce qui est probablement une bonne pratique de toute façon, même cette surcharge mineure sera évitée.

Aucune différence de performance. Cependant, vous utilisez des schémas en ce moment (même si vous ne le connaissez pas).

L'utilisation de références aux schémas d' objets tels que des tables, des procédures stockées, etc., UDFs qui sont non qualifié du schéma n'ont un impact sur les performances. Les références doivent toujours être qualifiées par schéma. Ces références non qualifiées doivent être résolues, et cela se produit comme ceci:

• Tout d'abord, recherchez un objet du même nom et du même type sous le schéma par défaut de l'utilisateur sous les informations d'identification de la session (par exemple jsmith). S'il est trouvé, cette instance est utilisée.
• Sinon, recherchez un objet du même nom et tapez sous le schéma dbo.

Cela a plusieurs effets:

• La plupart du temps, deux recherches sont nécessaires pour résoudre la référence plutôt que la recherche unique requise si la référence est qualifiée de schéma.
• Le plan d'exécution obtenu lorsque la requête / procédure stockée / fonction définie par l'utilisateur est liée ne peut pas être mis en cache et réutilisé.

L'effet final que vous ne constaterez - douloureusement - que lorsque quelque chose se brise est que différents utilisateurs peuvent obtenir des résultats différents à partir d'une requête ou d'une procédure stockée donnée. Quelque chose comme ça select * from foo join barpeut bien fonctionner pour moi en tant que propriétaire de la base de données; il peut être rompu pour l'utilisateur jsmithqui, par inadvertance ou non, a créé une table nommée foosous son propre schéma ( jsmith.foo) dans la même base de données.

Pour cette raison aussi, createet les dropdéclarations devraient schéma qualifier le nom de l'objet créé ou supprimé.