Ajout de vues à une base de données et à des performances fournies par le fournisseur

Question

Nous avons une base de données fournie par le fournisseur à laquelle j'ai pu éviter toute modification de structure de base de données. Nous interrogerons directement les tables directement pour un projet connexe. Afin de tirer toutes les données dont nous avons besoin, nous aurons besoin de créer une grosse instruction SQL avec plusieurs syndicats.

select ... from table1 
union 
select ... from table2 
... 
select ... from tableN 

La vitesse est la priorité absolue pour ce projet. Serait-il plus rapide de créer une vue pour effectuer les jointures, puis de simplement interroger cette vue (et donc de modifier la base de données du fournisseur) ou simplement exécuter l'instruction union à partir de notre application? Je connais les problèmes potentiels impliqués dans les modifications apportées à la base de données des fournisseurs, donc pourquoi je suis à la recherche de commentaires.

Answer 1

En ce qui concerne les bases de données des fournisseurs, je serais très hésitant à apporter des modifications aux tables existantes. Ajouter quelque chose comme une vue semble un peu plus sûr puisque vous êtes le seul à l'utiliser. Ma plus grande préoccupation avec la vue serait si vous avez reçu une mise à jour de votre fournisseur qui a apporté des modifications à votre base de données et vous pourriez perdre la vue.

Je ne pense pas que vous verriez des gains de performance en utilisant la vue, sauf si vous avez utilisé une vue indexée. Malheureusement, vous ne pouvez pas créer d'index sur une vue créée à l'aide d'une union (au moins dans SQL Server). Personnellement, quand il s'agit de mettre de la logique dans une application et de la mettre dans le DB, je me tourne vers DB. D'après mon expérience, ces types de changements sont plus faciles à déployer et à maintenir.

Si j'étais dans votre situation, je voudrais aller de l'avant créer la vue si cela va vous rendre la vie plus facile. Mais encore une fois, ne vous attendez pas à des gains de performance.

Answer 2

Aucune vue ne sera plus rapide (sauf pour le temps de développement).

Ce qui serait plus rapide serait d'utiliser UNION ALL si cela fonctionne. UNION recherche les enregistrements dupliqués et les supprime du résultat final. Si vous connaissez les enregistrements par conception (comme chaque table est pour un clin d'œil différent ou que chaque table a une plage de dates différente) ne peut pas être dupliquée, UNION ALL ne cherche pas à DISTINCTION le résultat et s'exécute donc beaucoup plus rapidement.