La vue imbriquée est-elle une bonne conception de base de données?
J'ai lu quelque part il y a longtemps. Le livre indique que nous ne devons pas autoriser une vue imbriquée dans SQL Server. Je ne suis pas sûr de la raison pour laquelle nous ne pouvons pas faire cela ou je me souviens peut-être d'une déclaration incorrecte.
étudiants
SELECT studentID, first_name, last_name, SchoolID, ... FROM students
CREATE VIEW vw_eligible_student
AS
SELECT * FROM students
WHERE enroll_this_year = 1
Enseignants
SELECT TeacherID, first_name, last_name, SchoolID, ... FROM teachers
CREATE VIEW vw_eligible_teacher
AS
SELECT * FROM teachers
WHERE HasCert = 1 AND enroll_this_year = 1
Écoles
CREATE VIEW vw_eligible_school
AS
SELECT TOP 100 PERCENT SchoolID, school_name
FROM schools sh
JOIN
vw_eligible_student s
ON s.SchoolID = sh.SchoolID
JOIN
vw_eligible_teacher t
ON s.SchoolID = t.SchoolID
Sur mon lieu de travail, j'ai étudié l'une de nos applications de base de données internes. J'ai vérifié à travers les objets que j'ai découvert qu'il y avait deux ou trois couches de la vue empilées. Cela m'a donc rappelé ce que j'ai lu dans le passé. Quelqu'un peut-il aider à l'expliquer?
Si ce n'est pas correct de le faire, je veux savoir qu'il est limité à SQL Server ou qu'il est destiné à la conception de bases de données en général.
Informations supplémentaires: j'ai mis à jour un exemple de mon entreprise. Je change un peu pour être plus général sans trop de technique (trop de colonnes dans cet exemple). La vue imbriquée que nous avons principalement utilisée est basée sur une vue abstraite ou agrégée. Par exemple, nous avons une grande table des étudiants avec des centaines de colonnes. Dire, Eligible Student View est basé sur les étudiants qui s'inscrivent cette année. Et la vue éligible des étudiants pourrait être utilisée dans d'autres endroits, comme dans la procédure stockée.
Quelle que soit la plateforme, les remarques suivantes s'appliquent.
(-) Vues imbriquées:
sont plus difficiles à comprendre et à déboguer
par exemple. À quelle colonne de table cette colonne d'affichage fait-elle référence? Lemme Dig through 4 niveaux de définitions de vue ...
il est plus difficile pour l'optimiseur de requêtes de trouver le plan de requête le plus efficace
Voir this , this , this , et this pour des preuves anecdotiques. Comparez avec this , ce qui montre que l'optimiseur est souvent assez intelligent pour décompresser correctement les vues imbriquées et sélectionner un plan optimal, mais pas sans coût de compilation.
Vous pouvez mesurer le coût des performances en comparant la requête de vue à une requête équivalente écrite par rapport aux tables de base.
(+) En revanche, les vues imbriquées vous permettent:
- centraliser et réutiliser des agrégations ou des règles métier
- éloignez votre structure sous-jacente (par exemple, d'autres développeurs de bases de données)
J'ai trouvé qu'ils sont rarement nécessaires.
Dans votre exemple, vous utilisez des vues imbriquées pour centraliser et réutiliser certaines définitions d'entreprise (par exemple, "Qu'est-ce qu'un étudiant éligible?"). Il s'agit d'une utilisation valide pour les vues imbriquées. Si vous maintenez ou optimisez cette base de données, pesez le coût de leur conservation par rapport à leur suppression.
Conserver: en conservant les vues imbriquées, vous obtenez les avantages et les inconvénients énumérés ci-dessus.
Supprimer: pour supprimer les vues imbriquées:
Vous devez remplacer toutes les occurrences des vues par leurs requêtes de base.
Vous devez vous rappeler de mettre à jour toutes les requêtes pertinentes si votre définition d'élève/enseignant/école éligible change, au lieu de simplement mettre à jour la définition de vue pertinente.
Parfois, les vues imbriquées sont utilisées pour empêcher la répétition des agrégats. Disons que vous avez une vue qui compte les messages et les regroupe par ID utilisateur, vous pouvez avoir une vue sur celle qui compte le nombre d'utilisateurs qui ont> 100 messages, ce genre de chose. Ceci est plus efficace lorsque la vue de base est une vue indexée - vous ne voulez pas nécessairement créer une autre vue indexée pour représenter les données avec un regroupement légèrement différent, car maintenant vous payez deux fois pour la maintenance de l'index où les performances sont probablement adéquat par rapport à la vue d'origine.
Si ce ne sont que des vues imbriquées dans lesquelles vous effectuez une sélection * mais en changeant l'ordre ou le sommet, il semble que cela serait mieux encapsulé en tant que procédure stockée avec des paramètres (ou des fonctions de valeur en ligne) qu'un groupe de vues imbriquées. A MON HUMBLE AVIS.
Les versions ultérieures de SQL (2005+) semblent meilleures pour optimiser l'utilisation des vues. Les vues sont les meilleures pour consolider les règles métier. EG: où je travaille, nous avons une base de données de produits de télécommunications. Chaque produit est affecté à un plan tarifaire, et ce plan tarifaire peut être échangé, et les tarifs sur le plan tarifaire peuvent être activés/désactivés à mesure que les tarifs sont augmentés ou modifiés.
Pour vous faciliter la tâche, nous pouvons créer des vues imbriquées. La première vue joint simplement les plans de taux à leurs taux en utilisant toutes les tables nécessaires, et en renvoyant toutes les données nécessaires dont les prochains niveaux de vue auraient besoin. Les 2e (s) vue (s) peuvent isoler uniquement les plans de taux actifs et leurs taux actifs. Ou, juste les tarifs clients. Ou les tarifs employés (pour les remises accordées aux employés). Ou les tarifs des clients professionnels et résidentiels. (les plans tarifaires peuvent se compliquer). Le fait est que la vue de base garantit que notre logique commerciale globale pour les plans de tarifs et les tarifs sont correctement réunis en un seul endroit. La couche de vues suivante nous donne plus de concentration sur des plans de taux spécifiques (types, actifs/inactifs, etc.).
Je suis d'accord que les vues peuvent rendre le débogage compliqué si vous créez des requêtes et des vues en même temps. Mais, si vous utilisez une vue éprouvée et approuvée, cela facilite le débogage. Vous savez que la vue a déjà traversé la sonnerie, vous savez donc que cela ne cause probablement pas le problème.
Cependant, des problèmes peuvent surgir avec votre point de vue. "Et si un produit n'est associé qu'à un plan tarifaire inactif?" ou "que se passe-t-il si un plan tarifaire ne comporte que des taux inactifs?" Eh bien, cela peut être pris au niveau frontal avec une logique qui détecte les erreurs des utilisateurs. "Erreur, le produit est sur un plan tarifaire inactif ... veuillez corriger". Nous pouvons également exécuter des audits de requête pour le vérifier avant une exécution de facturation. (sélectionnez tous les plans et joignez-vous à gauche pour afficher le plan tarifaire actif, ne renvoyez que les plans qui n'obtiennent pas de plan tarifaire actif en tant que problèmes à résoudre).
La bonne chose à ce sujet est que les vues vous permettent de condenser considérablement les requêtes de rapports, de facturation, etc. Vous pouvez avoir une vue de compte client, puis une vue de deuxième niveau des clients uniquement actifs. Faites équipe avec une vue de l'adresse du client. Équipe cela avec une vue de produit (s) (joint sur quel (s) produit (s) le client a). Faites équipe pour voir le plan tarifaire des produits. Faites équipe avec une vue des caractéristiques du produit. Visualisez, visualisez, visualisez, chaque essai sans erreur pour garantir l'intégrité. Votre requête finale utilisant les vues est très compacte.
éditer:
Comme exemple de la façon dont la vue aurait été meilleure qu'une simple requête de tables ... nous avons fait appel à un entrepreneur temporaire pour apporter des modifications. Ils lui ont dit qu'il y avait des points de vue sur les choses, mais il a décidé d'aplatir toutes ses requêtes. La facturation faisait disparaître certaines de ses requêtes. Ils ont continué à obtenir plusieurs plans tarifaires et tarifs sur les choses. Il s'avère que ses requêtes manquaient de critères pour autoriser la facturation des tarifs uniquement s'ils se situaient entre les dates de début et de fin pendant lesquelles le plan tarifaire était censé utiliser ces tarifs. Oops. S'il avait utilisé ce point de vue, il aurait déjà tenu compte de cette logique.
Fondamentalement, vous devez peser les performances par rapport à la raison. Vous pouvez peut-être faire toutes sortes de choses fantaisistes pour augmenter les performances d'une base de données. Mais, si cela signifie que c'est un cauchemar pour une nouvelle personne de prendre le relais/de maintenir, cela en vaut-il vraiment la peine? Est-ce que cela vaut vraiment la peine que le nouveau mec ait à jouer à Whack-a-mole pour trouver toutes les requêtes qui ont besoin de changer sa logique (et de le risquer de les oublier/de les doigter) b/c quelqu'un a décidé que les vues étaient "mauvaises" et n'a pas consolidé une logique métier de base en une logique qui pourrait être utilisée dans des centaines d'autres requêtes? Cela dépend vraiment de votre entreprise et de votre équipe IT/IS/DB. Mais, je préfère la clarté et la consolidation à source unique aux performances.
Le vrai problème n'est pas les vues imbriquées en soi. Le vrai problème est la prolifération des vues imbriquées alors que les développeurs ajoutent des modifications supplémentaires aux vues existantes. J'ai trouvé des requêtes avec une vue imbriquée 4 couches qui se sont effectivement jointes à l'une des vues de sa définition. Notre tendance à choisir la solution de facilité plutôt que d'analyser et de résoudre un problème est à l'origine du problème.
Dans mon environnement, nous répliquons de nombreuses tables du serveur de production vers le serveur de rapports. Sur le serveur de rapports, nous avons de nombreuses vues basées sur des tables de production répliquées ET imbriquées. Avant le démarrage de la réplication, nous devons supprimer toutes les vues pour rendre la réplication possible (nous utilisons drop et create car la structure des tables change souvent en production). Une fois la réplication terminée, nous devons reconstruire toutes les vues.
Maintenant, voici la partie amusante: Étant donné que de nombreuses vues sont imbriquées, nous devons les reconstruire dans un ordre spécifique. Lors de toute modification de la définition des vues, nous devons veiller à conserver le bon ordre de reconstruction. C'est un gâchis total. Je déconseille fortement d'utiliser des vues imbriquées si vous utilisez la réplication ou simplement supprimez et reconstruisez vos tables, qui sont la source des vues.
La performance est autre chose. Les vues basées sur d'autres vues ne sont rien d'autre que plusieurs requêtes à exécuter. Il est plus facile de rassembler la plus grande requête, de créer un travail et d'en faire un tableau. Plus facile et améliore les performances.