Gibt es einen Grund, in Oracle keine Views zu verwenden?

Question

Ich habe kürzlich festgestellt, dass in meinem Unternehmen (und es ist ein großes Unternehmen) niemand Ansichten verwendet.

Ich möchte einige Ansichten erstellen, vor allem, weil sie meine Abfragen für das Auge einfacher machen, und diese Ansichten sind auf etwas große Tabellen, die nicht sehr häufig aktualisiert werden (einmal pro Tag).

Meine Alternative ist, eine Tabelle des Typs record zu erstellen und sie bei jedem Aufruf eines SP zu füllen. Ist dies besser als die Verwendung einer Ansicht? (meine Vermutung ist nein)

PS: Die Datenbank ist Oracle 10g und EDIT: - Ja, ich habe herumgefragt, aber niemand konnte mir einen Grund nennen. - Sowohl die Ansichten als auch die Abfragen, die sie verwenden werden, sind stark auf Joins.

Answer 1

Ästhetik hat in SQL oder bei der Programmierung im Allgemeinen nichts zu suchen, wenn es um die Leistung geht.

Wenn der Optimierer feststellt, dass die Prädikatsverschiebung möglich ist, ist ein View so gut wie die direkte Abfrage der Tabelle(n), die der View darstellt. Und wie Justin erwähnt, da ein View ein Makro ist, das sich in die zugrunde liegende Abfrage, die der View darstellt, erweitert, ist ein Soft Parse (Wiederverwendung der Abfrage aus dem Cache) sehr wahrscheinlich, da die Cache-Prüfung Abfragen genau entsprechen muss.

Beachten Sie jedoch Folgendes:

• die Schichtung von Ansichten (eine Ansicht basiert auf einer anderen) ist eine schlechte Praxis - Fehler treten erst auf, wenn die Ansicht ausgeführt wird
• Das Verbinden von Ansichten mit anderen Tabellen oder Ansichten ist höchst verdächtig - der Optimierer sieht die Dinge möglicherweise nicht so gut, wenn die zugrunde liegende Abfrage anstelle des Verweises auf die Ansicht steht. Ich habe solche Erfahrungen gemacht, weil die Views, mit denen sie verbunden waren, mehr taten, als die Abfrage benötigte - manchmal wurden die Abfragen aller verwendeten Views zu einer einzigen Abfrage zusammengefasst, die viel besser lief.

Ich empfehle, Ihre Ansichten zu erstellen und die EXPLAIN-Pläne zu vergleichen, um sicherzustellen, dass Sie zumindest die gleiche Leistung erhalten. Ich müsste Ihren Code zum Auffüllen eines TYP sehen, bevor ich den Ansatz kommentieren kann, aber es klingt im Wesentlichen wie eine abgeleitete Tabelle...

Es ist möglich, dass Sie von der Verwendung von materialisierten Ansichten profitieren würden, aber sie sind notorisch eingeschränkt, was sie unterstützen.

Answer 2

In diesem Fall wäre es sicher hilfreich, einige Ansichten zu erstellen.

Haben Sie sich umgehört, warum niemand die Ansichten verwendet? Das erscheint recht merkwürdig und deutet darauf hin, dass Sie Ihr SQL nicht sehr effizient wiederverwenden. Ohne Sichten würden Sie dazu neigen, dieselbe Logik in viele verschiedene SQL-Anweisungen statt in eine einzige Sicht zu packen, was die Wartung mühsam machen würde.

Answer 3

Ein Grund, keine Ansichten zu verwenden, die gültig sein können oder auch nicht... ist, dass sie das Potenzial haben, Komplexität zu schaffen, wo es keine gibt

Ich könnte zum Beispiel schreiben

CREATE VIEW foo as <SOME COMPLEX QUERY>

dann könnte ich später schreiben

CREATE Procedure UseFoo as 
BEGIN
       SELECT 
          somefields
       FROM
          x 
          INNER JOIN foo
         .....

Jetzt erstelle ich also Objekte, die bereitgestellt, gewartet, versionskontrolliert usw. werden müssen.

Oder ich könnte entweder schreiben

CREATE Procedure UseFoo as 
BEGIN
       WITH foo as (<SOME COMPLEX QUERY>)
       SELECT 
          somefields
       FROM
          x 
          INNER JOIN foo
         .....

ou

CREATE Procedure UseFoo as 
BEGIN

       SELECT 
          somefields
       FROM
          x 
          INNER JOIN <SOME COMPLEX QUERY> foo
         .....

Und jetzt muss ich nur noch ein einziges Objekt bereitstellen, pflegen und versionskontrollieren.

Si <SOME COMPLEX QUERY> nur in einem Kontext existiert, ist die Pflege zweier getrennter Objekte eine unnötige Belastung. Auch nach der Bereitstellung werden alle Änderungen, die die Auswertung von Dingen erfordern, die sich auf UseFoo . Wenn zwei Objekte, die Sie brauchen, um etwas zu besuchen, die Bewertung auf UseFoo y Foo

Andererseits natürlich auch, wenn Foo eine gemeinsame Logik darstellt, ist die Auswertung ohnehin erforderlich, aber Sie müssen nur ein einziges Objekt finden und ändern.

Answer 4

Ich habe die Erfahrung gemacht, dass bei einer großen/komplexen Datenbank und einigen komplexen Abfragen keine Ansichten vorhanden sind, weil die Benutzer einfach nicht wissen, was Ansichten sind oder wie sie zu verwenden sind. Sobald ich die Vorteile der Verwendung einer Ansicht erklärt habe, haben die meisten Leute sie ohne Probleme verwendet.

Nach Ihrer Beschreibung würde ich nur eine Ansicht und keine neue Tabelle erstellen.

Answer 5

Ansichten sind großartig, um Komplexität zu verbergen - wenn Ihre Benutzer die von Ihnen erstellten Ansichten einfach so ausführen können (im Gegensatz zum Schreiben einer Abfrage gegen die Ansicht), ist das gut.

Wenn Ihre Benutzer wissen, wie man SQL schreibt, und die Tabellen verstehen, die sie verwenden, ist es vielleicht besser, sie das weiterhin tun zu lassen.

Bedenken Sie auch, dass gespeicherte Verfahren weniger anfällig für (dieselben) Leistungsprobleme sind wie Ansichten.