Ist es OK, Datenbankansichten zu verschachteln?

Question

In der Welt des Orakels habe ich den Eindruck, dass Ansichten, die auf anderen Ansichten basieren, als schlechte Praxis angesehen werden. Ich selbst habe mich darüber beschwert, als der Versuch, Leistungsprobleme zu lösen, und die Verschachtelung übertrieben schienen und unnötige Komplexität in den zugrunde liegenden Ansichten versteckten. Jetzt bin ich in der Situation, dass ich denke, dass es vielleicht nicht so eindeutig ist:

Ich habe Benutzer, die ganz gezielt die Buchhaltungszahlen einer Ansicht mit denen einer anderen Ansicht abgleichen müssen, in der sie weiterverarbeitet werden. Wenn sie in der einen Ansicht etwas ändern, soll die andere das sofort widerspiegeln, ohne dass jemand in ein paar Jahren an diese Anforderung denken muss und die Berichte nicht übereinstimmende Zahlen zeigen, während sie die Dinge herausfinden.

Ist es in diesem Fall in Ordnung, Ansichten zu verschachteln?

Ändert es etwas, wenn die innere Sicht eine weitere, wichtige Sicht enthält, die relevante Preise enthält (d.h. man soll diese Sicht "immer" bei der Preisermittlung verwenden)?

Answer 1

Das Hauptproblem bei der Verschachtelung von Ansichten ist, dass der Abfrageoptimierer eher verwirrt wird und einen suboptimalen Plan erstellt. Abgesehen davon gibt es keinen besonderen Overhead bei der Verwendung von Views auf Views, es sei denn, sie tun etwas, in das der Optimierer keine Prädikate einfügen kann.

Das bedeutet, dass die beste Option darin besteht, die verschachtelten Ansichten auszuprobieren. Sehen Sie, ob Sie vernünftige Abfragepläne aus den Berichten erhalten. Wenn dies zu Problemen führt, müssen Sie möglicherweise Ihre Strategie überdenken.

Answer 2

Ich werde nur aus der Perspektive der besten Praktiken antworten:

Es gibt nur wenige Fälle, in denen ich bei der Verwendung von Views on Views innehalten würde.

1. Die Verschachtelung scheint außer Kontrolle zu geraten ... über 3 Ebenen tief. Der Grund, warum ich verschachtelt bin, ist, den Code leichter zu pflegen zu machen. Sobald ich anfange, an diesen Punkt zu gelangen, wird es ein wenig zu kompliziert, um es zu verstehen.

2. Verschachtelung einer Ansicht, die analytische Funktionen verwendet. Ich persönlich habe, aus dem einen oder anderen Grund, keine guten Erfahrungen mit der Verschachtelung von Ansichten mit analytischen Funktionen gemacht.

3. Verschachtelte Ansichten, die von Natur aus vollständige Scans durchführen. Während ich denke, dass der Abfrageoptimierer wahrscheinlich intelligent genug ist, um dies zu behandeln, sieht es für mich einfach falsch aus, wenn ich die Logik der Ansicht überprüfe.

4. Die Leistung ist ein großes Anliegen. Das soll nicht heißen, dass der Optimierer es falsch machen könnte, aber bevor ich es freigebe, werde ich es testen, um zu sehen, ob ich nicht einen schnelleren Weg finden kann, es zu tun.

Ansonsten habe ich Ansichten auf Ansichten recht erfolgreich eingesetzt.

Answer 3

Ich glaube, Sie befinden sich hier auf einem schmalen Grat, auf dem die Wiederverwendung von Code und die Leistung in Konflikt geraten. Sie können es ausprobieren und sehen, wie stark es sich auf die Leistung auswirken wird. Wir haben hier einige Datenbanken, in denen Ansichten auf Ansichten gestapelt sind, und ehrlich gesagt ist die Leistung miserabel, und jetzt wünschen sich alle Beteiligten, sie hätten das nicht so gemacht.

Answer 4

Es gibt immer einen Kompromiss zwischen Codierzeit, Einfachheit oder Qualität des Codes und Leistung.

Die Verschachtelung von Ansichten ist wirklich einfach zu programmieren und unter den richtigen Umständen auch leicht zu lesen. Es kann auch Zeit sparen. Es reduziert wohl die Qualität und oft auch die Leistung... aber um wie viel?

Das ist alles subjektiv. Wenn es Sinn macht, machen Sie mit. Optimieren Sie Ihren Code nicht voreilig.

Answer 5

Die besten Praktiken decken nicht immer alles ab. Ich denke, Sie haben eine klare Rechtfertigung für die Verschachtelung, nur dieses eine Mal.