Downsides à « AVEC SCHEMABINDING » dans SQL Server?

StackOverflow https://stackoverflow.com/questions/1659320

Question

J'ai une base de données avec des centaines de tables nommées gauchement en elle (CG001T, GH066L, etc.), et j'ai vues sur chacun avec son nom « convivial » (la vue « clients » est « SELECT * FROM GG120T », par exemple). Je veux ajouter « AVEC SCHEMABINDING » à mon point de vue afin que je puisse avoir quelques-uns des avantages qui y sont associés, comme être en mesure d'indexer la vue, car une poignée de vues ont calculé les colonnes qui sont coûteuses à calculer à la volée.

Y at-il des inconvénients à SCHEMABINDING ces vues? J'ai trouvé quelques articles qui font allusion vaguement aux inconvénients, mais ne vont jamais dans les détails. Je sais qu'une fois vue est schemabound, vous ne pouvez pas modifier tout ce qui aurait un impact sur la vue (par exemple, un type de colonne ou collation) sans laisser tomber la vue, de sorte que l'un est, mais à part cela? Il semble que la capacité d'indexer la vue elle-même dépasseraient largement les inconvénients de la planification de vos modifications de schéma plus attentivement.

Était-ce utile?

La solution

Pas du tout. Il est plus sûr. nous utilisons partout.

Autres conseils

Vous ne serez pas en mesure de modifier / supprimer la table, à moins que vous laissez tomber la vue d'abord.

Oh, il y a DEFINITIF Downsides à l'utilisation SCHEMABINDING - ceux-ci proviennent de fait la SCHEMABINDING, en particulier lorsqu'il est couplé avec des colonnes Computed "BLOCAGE" LES RELATIONS et fait quelques « trivial changements » darn presque impossible.

  1. Créer une table.
  2. Créer une SCHEMABOUND UDF.
  3. Créer une colonne PERSISTED CALCULÉ qui fait référence à l'UDF.
  4. Ajoutez un indice sur la colonne.
  5. Essayez de mettre à jour l'UDF.

Bonne chance avec celui-là!

  1. L'UDF ne peut être supprimé ou modifié car il est SCHEMABOUND.
  2. La colonne ne peut pas être supprimé car il est utilisé dans un index.
  3. La colonne ne peut pas être modifié car il est calculé.

Eh bien, Frak. Vraiment..!?! Ma journée est juste devenu un PITA. (Maintenant, des outils comme ApexSQL Diff peuvent gérer ce lorsqu'il est fourni avec un schéma modifié , mais le problème est que je ne peux même modifier le schéma pour commencer!)

Je ne suis pas contre SCHEMABINDING, l'esprit (et il est nécessaire pour une UDF dans ce cas), mais Je suis contre il ne pas être un moyen (que je peux trouver) pour « désactiver temporairement » la SCHEMABINDING .

Si ces tableaux sont d'une application tierce (ils sont connus pour essayer cacher leurs tables), vous causez et la mise à niveau à l'échec si elle tente de modifier l'une de ces tables.

Il suffit de modifier les vues sans SCHEMABINDING avant la mise à jour / mise à niveau, puis les remettre. Comme d'autres l'ont mentionné. Prend juste un peu de planification, discipline, etc.

Un inconvénient est que si vous schemabind une vue, il ne peut faire référence à d'autres vues de schemabound.

Je le sais parce que j'ai essayé de schemabind une vue et a été rencontré un message d'erreur me disant qu'il ne pouvait pas être schemabound parce que l'un des autres points de vue auxquels il fait référence n'est pas aussi schemabound.

La seule conséquence de ceci est que si vous voulez soudainement mettre à jour une vue schemabound pour faire référence à une vue nouvelle ou existante, vous pourriez avoir à ce point de vue schemabind nouvelles ou existantes ainsi. Dans ce cas, vous ne serez pas en mesure de mettre à jour la vue, et mieux vous espérons que vos développeurs de bases de données savent comment travailler avec vue sur la schemabound.

Un autre inconvénient est que vous devez utiliser des noms qualifiés de schéma pour tout: Vous aurez une charge de messages d'erreur comme ceci:

  

Impossible de schéma vue bind « view » parce que le nom « table » est invalide pour   liaison de schéma. Les noms doivent être au format en deux parties et un objet ne peut pas   elle-même référence.

Aussi « éteindre » SCHEMABINDING vous ne modifiez point de vue qui vous oblige à redéfinir l'instruction select de la vue. Je pense que la seule chose que vous n'avez pas à redéfinir est des subventions. Cela me met hors beaucoup comme la vue semble écraser comme une opération dangereuse en soi.

Il est un peu comme la façon d'ajouter pas les forces de contraintes nulles que vous écrasez le type de données de la colonne - méchante

Vous devrez également redéfinir toutes les autres vues ou procédures qui dépendent du schéma objet lié vous voulez changer ... cela signifie que vous pourriez avoir à redéfinir (et peut-être briser) une grande cascade de fonctions et vues juste ajouter (par exemple) une contrainte non nulle à une colonne.

Personnellement, je pense que cela ne marche pas vraiment représenter une solution et son mieux d'avoir un processus décent par lequel tout changement de base de données sont automatiquement appliquées de sorte qu'il n'est pas un cauchemar pour changer la base de données. De cette façon, vous pouvez avoir toutes vos vues + fonctions supprimée et recréée à partir de zéro (ils sont contrôlés sur la création de toute façon) dans le cadre du processus lorsque vous appliquez des modifications aux tables.

cela semble être un inconvénient pour moi (# 's sont à moi): 

Cannot create index on view "###.dbo.###" because it uses a LEFT, RIGHT, or FULL OUTER join, and no OUTER joins are allowed in indexed views. Consider using an INNER join instead.

J'ai besoin un peu ma gauche rejoint. Cette question SO est pertinente.

Lors de l'utilisation Unit Test Framework tSQLt vous rencontrerez des problèmes et des solutions de contournement aurez besoin lors de l'utilisation méthode FakeTable, qui ne vous permettra pas à une table de faux qui est lié à une vue avec SCHEMABINDING.

Les négatifs mentionnés dépassent à peine cette meilleure pratique depuis SQL SVR 2005. Il évite la mise en attente de la table redoutée. Un grand point négatif pour moi est que schéma lié sprocs, funcs, vues, ne peuvent pas inclure des bases de données « étrangers » comme le db maître, donc vous pouvez jeter toutes les grandes choses du système en temps réel à la poubelle à moins que, par exemple, le cœur de votre production base de données se trouve à l'intérieur de maître. Pour moi, je ne peux pas faire face à la vie sans les trucs sys. Bien sûr, pas tout le traitement nécessite des performances sans bobine et des résultats rapides et lents peuvent être combinés simultanément dans les couches de la classe de données plus élevées.

Si votre outil (SSMS, etc.) ne vous pourrait gérer pas les défaillances de changement de schéma sur l'objet de base et / élégance vous causer un peu de chaos réel. Voilà ce que je suis assis avec, et je me rends compte que c'est un cas marginal

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top