Sql Server 2008 Vues d'imbrication

Question

Existe-t-il une bonne pratique générale sur l'utilisation ou non des vues imbriquées? Existe-t-il un problème de performances lors de l'utilisation de vues imbriquées? Y a-t-il une meilleure pratique qui dit qu'il n'y a vraiment pas un coup de performance jusqu'à ce que vous ayez 4 couches ou plus de profondeur?

La raison pour laquelle je pose cette question est parce que j'ai du mal à les utiliser ou non. Il n'est pas rare d'obtenir une demande de rapport dont la seule façon d'accéder à cette information est de joindre 20 tables ou plus ensemble. Les champs ne sont pas retournés à partir de toutes les tables mais sont nécessaires pour sélectionner les données correctes. Dans ce cas, j'aime imbriquer les vues et réutiliser les vues de niveau inférieur pour les autres rapports, car si une modification de la logique est nécessaire, je mets à jour une vue et tous les rapports sont mis à jour. La plupart des tables avec lesquelles je travaille contiennent des millions et des millions d'enregistrements.

Cependant, ce n'est peut-être pas une bonne pratique. Cela vous dérange-t-il de partager vos pensées à ce sujet?

Answer 1

Je voudrais éviter cela à tout prix. D'abord, une fois que vous avez imbriqué des vues, elles ne peuvent pas être indexées. Ensuite, puisqu'ils doivent matérialiser complètement les vues sous-jacentes pour arriver à la couche suivante. Vous pourriez ainsi matérialiser des millions d'enregistrements pour obtenir un résultat final de 5 enregistrements. Nous avons failli perdre un client de plusieurs millions de dollars parce que la performance était tellement épouvantable quand nos développeurs l'ont fait sur une base de données (pas une base de données que j'avais contribué à la conception de).

Enfin, j'ai trouvé que ces types de couches sont beaucoup, beaucoup plus difficiles à maintenir lorsque vous avez besoin de faire un changement. Ce n'est pas amusant de suivre 12 couches de vues pour trouver celle que vous devez corriger. Nous avons également rencontré un problème car les développeurs trouvaient plus simple d'ajouter une autre couche que de réparer les couches sous-jacentes et essayaient d'accéder à trop de tables dans une requête, et trop d'entre elles étaient la même table d'enregistrements multi-million 7 ou 8 fois dans différentes couches des vues.

Il n'y a aucune circonstance où j'autoriserais plus d'une couche dans une vue dans une base de données que je gère et je serais en colère si vous faisiez cela.

Answer 2

Autres options à considérer: Vues indexées - Peut être dangereux à utiliser s'il n'est pas utilisé correctement mais les gains de performances peuvent être incroyables.

Analytics - tels que le regroupement définit

procédures & tables temporaires - Obtenir les données dont vous avez besoin via la procédure écrire sur des tables temporaires sélectionner des tables de temp.

Dans l'ensemble, je n'aime pas l'impact de la performance sur la vue sur la vue ou les vues imbriquées.

Généralement, vous pouvez générer une vue en utilisant les bonnes jointures entre les tables qui contiennent toutes les informations après et filtrer les données en utilisant des critères.