it-swarm.com.de

Ist verschachtelte Ansicht ein gutes Datenbankdesign?

Ich habe vor langer Zeit irgendwo gelesen. Das Buch besagt, dass wir keine verschachtelte Ansicht in SQL Server zulassen sollten. Ich bin mir nicht sicher, warum wir das nicht können, oder ich erinnere mich an eine falsche Aussage.

Studenten

SELECT studentID, first_name, last_name, SchoolID, ... FROM students

CREATE VIEW vw_eligible_student
AS 
SELECT * FROM students
WHERE enroll_this_year = 1

Lehrer

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

Schulen

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

An meinem Arbeitsplatz habe ich eine unserer internen Datenbankanwendungen untersucht. Ich habe die Objekte durchgesehen und festgestellt, dass sich zwei oder drei Ebenen des Ansichtsstapels befinden. Das erinnerte mich an das, was ich in der Vergangenheit gelesen hatte. Kann jemand helfen, es zu erklären?

Wenn dies nicht in Ordnung ist, möchte ich wissen, dass es nur auf SQL Server beschränkt ist oder für das Datenbankdesign im Allgemeinen.

Zusätzliche Informationen: Ich habe ein Beispiel aus meiner Firma aktualisiert. Ich ändere mich ein wenig, um allgemeiner zu sein, ohne zu viele technische (zu viele Spalten in diesem Beispiel). Die von uns verwendete verschachtelte Ansicht basiert größtenteils auf einer abstrakten oder aggregierten Ansicht. Zum Beispiel haben wir eine große Schülertabelle mit Hunderten von Spalten. Sagen, Eligible Student View basiert auf Studenten, die sich in diesem Jahr einschreiben. Die schülerberechtigte Ansicht könnte auch an anderen Stellen verwendet werden, z. B. in gespeicherten Prozeduren.

43

Unabhängig von der Plattform gelten die folgenden Anmerkungen.

(-) Verschachtelte Ansichten:

  • sind schwerer zu verstehen und zu debuggen

    z.B. Auf welche Tabellenspalte bezieht sich diese Ansichtsspalte? Lemme Dig through 4 Ebenen von Ansichtsdefinitionen ...

  • machen Sie es dem Abfrageoptimierer schwerer, den effizientesten Abfrageplan zu erstellen

    Siehe this , this , this und this für anekdotische Beweise. Vergleichen Sie mit this , was zeigt, dass das Optimierungsprogramm häufig intelligent genug ist, um verschachtelte Ansichten korrekt zu entpacken und einen optimalen Plan auszuwählen, jedoch nicht ohne Kompilierungskosten.

    Sie können die Leistungskosten messen, indem Sie die Ansichtsabfrage mit einer entsprechenden Abfrage vergleichen, die für die Basistabellen geschrieben wurde.

(+) Auf der anderen Seite können Sie mit verschachtelten Ansichten:

  • aggregationen oder Geschäftsregeln zentralisieren und wiederverwenden
  • abstrahieren Sie Ihre zugrunde liegende Struktur (z. B. von anderen Datenbankentwicklern)

Ich habe festgestellt, dass sie selten notwendig sind.


In Ihrem Beispiel verwenden Sie verschachtelte Ansichten, um bestimmte Geschäftsdefinitionen zu zentralisieren und wiederzuverwenden (z. B. "Was ist ein berechtigter Schüler?"). Dies ist eine gültige Verwendung für verschachtelte Ansichten. Wenn Sie diese Datenbank pflegen oder optimieren, wägen Sie die Kosten für die Aufbewahrung gegen die Kosten für die Entfernung ab.

  • Behalten: Wenn Sie die verschachtelten Ansichten beibehalten, entstehen die oben aufgeführten Vor- und Nachteile.

  • Entfernen: So entfernen Sie die verschachtelten Ansichten:

    1. Sie müssen alle Vorkommen der Ansichten durch ihre Basisabfragen ersetzen.

    2. Sie müssen daran denken, alle relevanten Abfragen zu aktualisieren, wenn sich Ihre Definition des berechtigten Schülers/Lehrers/der Schule ändert, anstatt nur die relevante Ansichtsdefinition zu aktualisieren.

47
Nick Chammas

Manchmal werden verschachtelte Ansichten verwendet, um zu verhindern, dass sich Aggregate wiederholen. Angenommen, Sie haben eine Ansicht, in der Nachrichten gezählt und nach Benutzer-ID gruppiert werden. Möglicherweise haben Sie eine Ansicht darüber, in der die Anzahl der Benutzer mit> 100 Nachrichten gezählt wird. Dies ist am effektivsten, wenn es sich bei der Basisansicht um eine indizierte Ansicht handelt. Sie möchten nicht unbedingt eine weitere indizierte Ansicht erstellen, um die Daten mit einer etwas anderen Gruppierung darzustellen, da Sie jetzt für die Indexpflege zweimal bezahlen, wenn die Leistung wahrscheinlich ist angemessen gegen die ursprüngliche Ansicht.

Wenn dies alles nur verschachtelte Ansichten sind, in denen Sie select * ausführen, aber die Reihenfolge oder den oberen Rand ändern, ist dies anscheinend besser als gespeicherte Prozedur mit Parametern (oder Funktionen mit Inline-Tabellenwerten) gekapselt als eine Reihe verschachtelter Ansichten. MEINER BESCHEIDENEN MEINUNG NACH.

26
Aaron Bertrand

Spätere Versionen von SQL (2005+) scheinen die Verwendung von Ansichten besser zu optimieren. Ansichten eignen sich am besten zum Konsolidieren von Geschäftsregeln. EG: Wo ich arbeite, haben wir eine Telekommunikationsproduktdatenbank. Jedes Produkt ist einem Tarifplan zugeordnet, und dieser Tarifplan kann ausgetauscht werden, und die Tarife im Tarifplan können aktiviert/deaktiviert werden, wenn die Tarife erhöht oder geändert werden.

Um dies zu vereinfachen, können wir verschachtelte Ansichten erstellen. Die erste Ansicht verknüpft die Tarifpläne einfach mit ihren Tarifen unter Verwendung der benötigten Tabellen und gibt alle erforderlichen Daten zurück, die die nächsten Ansichtsebenen benötigen würden. 2. Ansicht (en) können nur aktive Tarifpläne und deren aktive Tarife isolieren. Oder nur Kundentarife. Oder Mitarbeitertarife (für Mitarbeiterrabatt). Oder Geschäfts- oder Privatkundenpreise. (Tarifpläne können kompliziert werden). Der Punkt ist, dass die Fundamentansicht sicherstellt, dass unsere gesamte Geschäftslogik für Tarifpläne und Tarife an einem Ort ordnungsgemäß miteinander verbunden sind. In der nächsten Ansichtsebene konzentrieren wir uns stärker auf bestimmte Tarifpläne (Typen, aktiv/inaktiv usw.).

Ich bin damit einverstanden, dass Ansichten das Debuggen unübersichtlich machen können, wenn Sie gleichzeitig Abfragen und Ansichten erstellen. Wenn Sie jedoch eine bewährte Ansicht verwenden, wird das Debuggen einfacher. Sie wissen, dass die Ansicht bereits den Klingelton durchlaufen hat, sodass Sie wissen, dass das Problem höchstwahrscheinlich nicht verursacht wird.

Es können jedoch Probleme mit Ihren Ansichten auftreten. "Was ist, wenn ein Produkt nur einem inaktiven Tarifplan zugeordnet ist?" oder "Was ist, wenn ein Tarifplan nur inaktive Tarife enthält?" Nun, das kann auf der Front-End-Ebene mit einer Logik abgefangen werden, die Benutzerfehler abfängt. "Fehler, Produkt befindet sich in einem inaktiven Tarifplan ... bitte korrigieren". Wir können auch Abfrageprüfungen durchführen, um sie vor einem Abrechnungslauf zu überprüfen. (Wählen Sie alle Pläne aus und verbinden Sie sie mit der aktiven Tarifplanansicht. Geben Sie nur Pläne zurück, die keinen aktiven Tarifplan erhalten, als Probleme, die behoben werden müssen.).

Das Gute daran ist, dass Sie mit den Ansichten Abfragen für Berichterstellung, Abrechnung usw. erheblich reduzieren können. Sie können eine Kundenkontenansicht und dann eine Ansicht der zweiten Ebene nur aktiver Kunden haben. Team das mit Blick auf die Kundenadresse. Kombinieren Sie dies mit Blick auf Produkte (verbunden mit den Produkten, die der Kunde hat). Kombinieren Sie das, um den Preisplan für Produkte anzuzeigen. Team das mit Blick auf Produktmerkmale. Anzeigen, Anzeigen, Anzeigen, jeder Versuch ist fehlerhaft, um die Integrität sicherzustellen. Ihre Endabfrage mit den Ansichten ist sehr kompakt.

bearbeiten:

Als Beispiel dafür, wie die Ansicht besser gewesen wäre als nur eine flache Abfrage von Tabellen ... Wir hatten einen Zeitarbeiter, der einige Änderungen vornahm. Sie sagten ihm, es gäbe Ansichten für Dinge, aber er beschloss, alle seine Fragen zu reduzieren. Billing ließ einige seiner Fragen hinter sich. Sie bekamen immer wieder mehrere Tarifpläne und Tarife für Dinge. Es stellte sich heraus, dass seinen Anfragen Kriterien fehlten, um die Abrechnung von Tarifen nur dann zu ermöglichen, wenn sie zwischen dem Start- und Enddatum lagen, für das der Tarifplan diese Tarife verwenden sollte. Hoppla. Wenn er die Ansicht verwendet hätte, hätte sie diese Logik bereits berücksichtigt.

Grundsätzlich muss man Leistung gegen Vernunft abwägen. Vielleicht können Sie alle möglichen ausgefallenen Dinge tun, um die Leistung einer Datenbank zu steigern. Aber wenn es bedeutet, dass es ein Albtraum für eine neue Person ist, zu übernehmen/zu warten, ist es das wirklich wert? Lohnt es sich wirklich, wenn der neue Kerl einen Schlag ins Maul spielt, um alle Fragen zu finden, die erforderlich sind, um seine Logik zu ändern (und zu riskieren, dass er sie vergisst/fettfingert)? Haben Sie nicht eine Kerngeschäftslogik zu einer konsolidiert, die in Hunderten anderer Abfragen verwendet werden könnte? Es liegt wirklich an Ihrem Unternehmen und Ihrem IT/IS/DB-Team. Ich würde jedoch Klarheit und Konsolidierung aus einer Hand der Leistung vorziehen.

7
blah blah

Das eigentliche Problem sind keine verschachtelten Ansichten an sich. Das eigentliche Problem ist die Verbreitung verschachtelter Ansichten, da Entwickler vorhandene Ansichten zusätzlich optimieren. Ich habe Abfragen mit einer verschachtelten Ansicht 4 Ebenen gefunden, die tatsächlich mit einer der Ansichten in ihrer Definition verbunden sind. Unsere Tendenz, den einfachen Ausweg zu finden, anstatt ein Problem zu analysieren und zu lösen, ist die Wurzel des Problems.

4
Ray

In meiner Umgebung replizieren wir viele Tabellen vom Produktionsserver auf den Berichtsserver. Auf dem Berichtsserver haben wir viele Ansichten, die auf replizierten Produktionstabellen basieren UND verschachtelt sind. Bevor die Replikation beginnt, müssen wir alle Ansichten entfernen, um die Replikation zu ermöglichen (wir verwenden drop and create, da sich die Tabellenstruktur in der Produktion häufig ändert). Nach Beendigung der Replikation müssen alle Ansichten neu erstellt werden.

Hier ist der lustige Teil: Da viele der Ansichten verschachtelt sind, müssen wir sie in einer bestimmten Reihenfolge neu erstellen. Bei Änderungen an der Ansichtsdefinition müssen wir darauf achten, dass die richtige Wiederherstellungsreihenfolge eingehalten wird. Es ist ein totales Durcheinander. Ich rate dringend davon ab, verschachtelte Ansichten zu verwenden, wenn Sie die Replikation verwenden oder einfach Ihre Tabellen löschen und neu erstellen, die als Quelle für Ansichten dienen.

Leistung ist eine andere Sache. Ansichten, die auf anderen Ansichten basieren, sind nichts anderes als mehrere auszuführende Abfragen. Es ist einfacher, die größere Abfrage zusammenzustellen, einen Job zu erstellen und daraus eine Tabelle zu erstellen. Einfacher und verbessert die Leistung.

0
Narwhal