SQL Server: dois-je utiliser des tables de schéma d'information sur des tables sys?

Sauf si vous écrivez une application dont vous savez pertinemment qu'elle devra être portable ou que vous ne voulez que des informations assez basiques, je voudrais simplement utiliser les vues système SQL Server propriétaires pour commencer.

Les vues Information_Schema n'affichent que les objets compatibles avec la norme SQL-92. Cela signifie qu'il n'y a pas de vue de schéma d'informations pour même des constructions assez basiques telles que les index (ceux-ci ne sont pas définis dans la norme et sont laissés comme détails d'implémentation.) Le laisser seul toutes les fonctionnalités propriétaires de SQL Server.

En outre, ce n'est pas tout à fait la panacée pour la portabilité que l'on peut supposer. Les implémentations diffèrent toujours entre les systèmes. Oracle ne l'implémente pas du tout "hors de la boîte" et les documents MySql disent:

Les utilisateurs de SQL Server 2000 (qui suit également la norme) peuvent remarquer une forte similitude. Cependant, MySQL a omis de nombreuses colonnes qui sont pas pertinent pour notre implémentation, et des colonnes ajoutées qui sont Spécifique à MySQL. Une telle colonne est la colonne moteur dans le INFORMATION_SCHEMA.TABLES table.

Même pour les constructions SQL bread and butter telles que les contraintes de clé étrangère, les vues Information_Schema peuvent être nettement moins efficaces que les vues sys. car elles n'exposent pas les ID d'objet qui permettraient une interrogation efficace.

E. g. Voir la question requête SQL ralentissement de 1 seconde à 11 minutes - pourquoi?{[9] } et exécution plan.

INFORMATION_SCHEMA

Sys

INFORMATION_SCHEMA est plus approprié pour le code externe qui peut avoir besoin d'interfacer avec une variété de bases de données. Une fois que vous commencez à programmer dans La base de données, la portabilité sort de la fenêtre. Si vous écrivez des procédures stockées, cela me dit que vous vous êtes engagé sur une plate-forme de base de données particulière (pour le meilleur ou pour le pire). Si vous avez validé SQL Server, utilisez les vues sys.

Je ne vais pas répéter certaines des autres réponses mais ajouter une perspective de performance. les vues information_schema, comme le mentionne Martin Smith dans sa réponse, ne sont pas la source la plus efficace de cette information car elles doivent exposer des colonnes standard qui doivent être collectées à partir de plusieurs sources sous-jacentes. les vues sys peuvent être plus efficaces de ce point de vue, donc si vous avez des exigences de performance élevées et que vous n'avez pas à vous soucier de la portabilité, vous devriez probablement utiliser sys vue.

Par exemple, la première requête ci-dessous utilise information_schema.tables pour vérifier si une table existe. Le second utilise sys.tables pour faire la même chose.

if exists (select * from information_schema.tables where table_schema = 'dbo' and table_name = 'MyTable')
    print '75% cost';

if exists (select * from sys.tables where object_id = object_id('dbo.MyTable'))
    print '25% cost';

Lorsque vous affichez les E / S pour ceux-ci, la première requête a 4 lectures logiques à sysschobjs et sysclsobjs, tandis que la seconde n'en a aucune. De plus, le premier effectue deux recherches d'index non clusterisées et une recherche de clé tandis que le second ne fait qu'une seule recherche d'index clusterisé. Le premier coûte ~3x plus que le second selon les plans de requête. Si vous devez le faire beaucoup de fois dans un grand système, par exemple pour le temps de déploiement, cela pourrait s'additionner et causer des problèmes de performances. Mais cela ne s'applique vraiment qu'aux systèmes fortement chargés. La plupart des systèmes informatiques n'ont pas ces niveaux de problèmes de performance.

Encore une fois, le coût global de ceux-ci sont très faibles individuellement par rapport à d'autres requêtes dans la plupart des systèmes, mais si votre système a beaucoup de ce type d'activité, il pourrait s'additionner.