Je crée une application Web qui possède des associations complexes sous-jacentes. Afin de résoudre plusieurs problèmes, j'ai créé une vue union. Il y a probablement beaucoup d'autres moyens pourraient être résolus.
Mais je compte maintenant que l'efficacité de ma conception et que je voulais savoir si une vue est créée récemment chaque fois qu'elle est interrogée, ou est-ce que cela n'a été créé qu'une seule fois et a été mis à jour.
Elaborer, si j'ai TABLE_A (100 enregistrements) et TABLE_B (100 enregistrements) et faites une vue union, j'ai créé une vue avec 200 enregistrements.
Est-ce que tout ce processus se produit chaque fois que je fais une sélection de la vue?
Encore une fois, évidemment chaque fois que je mettez à jour les enregistrements de la table sous-jacente La vue est mise à jour, mais la vue met-elle à jour celui-ci ou recrée-t-elle toute la vue de zéro?
Dale
3 Réponses :
Une vue n'est rien de plus qu'une requête avec un nom. Il existe des optimisations perfiées possibles, que certains SGBD se rendent mieux que d'autres (PGSQL semble être du meilleur côté), comme la réutilisation du plan de requête, le contrôle d'accès mis en cache, etc.
Cependant, à la fin de leur journée, presque toujours, vous pouvez vous attendre à ce que la vue se comporte comme émettre le SQL directement. Avec la différence que vous pouvez accorder un accès à cette requête sans accéder aux tables sous-jacentes.
Il existe des optimisations que vous pourriez faire ce qui modifie le comportement (de les faire demi-table) et que cela pourrait ou non exister dans PGSQL comme des vues matérialisées (désolé aucune idée de PGSQL), mais cela ne vient pas de nitpicking.
Est-ce que tout ce processus se produit chaque fois que je fais une sélection de la vue?
Oui.
Une vue non matérialisée (PostgreSQL ne prend pas en charge les vues matérialisées) est simplement une instruction SQL préparée - vous obtiendrez la même performance en remplaçant une référence de vue avec une sous-requête contenant le SELECT que la vue est basée sur.C'est pourquoi les valeurs basées sur les tables de support apparaissent chaque fois que vous exécutez une requête à la vue, je ne suis pas claire si les manipulations de colonne sont rendues visibles dans PostgreSQL sans rafraîchir la vue - IE: Si vous créez une vue sur la page. Sélectionnez * à partir de table_x, puis ajoutez ou supprimez une colonne de table_x - la plupart des bases de données vous demanderont de vous rafraîchir la vue pour voir ce changement via la vue.
Les vues du bâtiment sur les points de vue doivent être découragées - elles sont fragiles; Vous ne saurez pas avant d'avoir exécuté une vue dépendante d'un autre s'il y a un problème. Et il n'y a pas de gain de performance - plutôt le contraire. La réutilisation de code ne fonctionne pas bien dans un environnement défini ...
Postgres prend en charge des vues matérialisées depuis 9.3 Postgresql.org/docs/9.3/Static /sql-creatematerializedView.ht ml
Utilisez Expliquer pour voir comment une vue est exécutée, vous verrez les mêmes résultats qu'une requête normale.
EXPLAIN SELECT * FROM name_of_your_view WHERE foo = 23;
Merci frank. Essayer d'utiliser la méthode d'explication, mais je ne reçois rien de sens dans la réponse. Je comprends maintenant qu'une vue est vraiment juste une déclaration de requête. Ce que je veux savoir maintenant, c'est, si je fais un choix par rapport à la vue, la requête est-elle d'abord recherchée toutes les lignes pour créer la vue, puis regarder toutes les lignes pour effectuer la sélection? Ou est-ce plus efficace que cela?
C'est la requête Explique que j'ai faite: expliquer Select * de Person_Roles où Person_id = 3; Et ceci est le résultat: trier (coût = 2.95..2,97 lignes = 9 largeur = 42) TRY KEY: PUBLICK.LINKS.CREATED_AT -> HASHAGREGRÉE (COÛT = 2.71..2.80 ROWS = 9 LARGEUR = 42) -> ANNEXE ( Coût = 0,00..2,46 lignes = 9 largeur = 42) -> SEQ Numérisation sur les liens (Coût = 0,00..1,19 lignes = 5 largeur = 42) Filtre: (origin_id = 3) -> SEQ Numérisation sur les liens (Coût = 0,00 ..1.1.19 ROWS = 4 largeur = 42) Filtre: (rcvd_id = 3)
PostgreSQL est très intelligent, ne vous inquiétez pas. L'optimiseur vérifie les statistiques sur les tables de votre requête, vérifie les index disponibles et les relevés où les déclarations. L'optimiseur réécrit votre requête puis est-ce que c'est magique de savoir ce que Queryplan serait le plus rapide. Dans votre cas, il utilise des scans séquentiels et n'utilisez aucun index. Je suppose que la quantité de données est très limitée, mais elle pourrait également être que vous n'avez pas d'index sur les colonnes origines_id et rcvd_id. Vérifiez Postgresql.org/docs/Current/interactive/... lire comment les choses fonctionnent.
BTW, un
insert peut affecter une seule table à la fois, de sorte que votre vue est doncjoindre sur plusieurs tables, votreinsérer ne peut indiquer que colonnes de l'une des tables.