Eine Einführung in MySQL 5 Ansichten

Die MySQL 5-Serie führte einige Änderungen ein. Auslöser und gespeicherte Prozeduren waren zwei der großen Ticketobjekte. Eine der weniger bekannten Ergänzungen, zumindest aus dem Umfang der Schrift zu diesem Thema, ist die Einführung von Ansichten. Nach einem kurzen Blick auf die MySQL-Ansichten sehen Sie möglicherweise nicht die offensichtlichen Vorteile. Sie sind vorhanden, wenn Sie nur ein wenig in sie hineinschauen.


Einführung: Was ist eine Ansicht?

"Ein View ist nichts anderes als eine Pseudo-Tabelle, die die Arbeit einer definierten Abfrage ausführt."

Kurz gesagt, der einfachste Weg, eine Ansicht zu betrachten, besteht darin, dass es sich lediglich um eine gespeicherte Abfrage handelt, die eine Tabelle nachahmt. Es ist nicht mehr als eine Pseudo-Tabelle, die die Arbeit einer definierten Abfrage ausführt. Es werden keine Funktionen hinzugefügt, z. B. das Ändern von Variablen, und es werden auch keine anderen Abfragen ausgelöst, wenn etwas anderes passiert. Ansichten sitzen einfach da, dumm und dumm und machen das, wozu Sie sie bestimmt haben.

Beim ersten Anblick hört sich das nicht nach einem großen Deal an, aber wenn Sie an der Oberfläche vorbeischauen, können Sie etwas von der Kraft der niedrigen Ansicht erkennen. Ich werde nicht sagen, dass Ansichten Ihr Leben verändern werden, aber ich sage Ihnen, dass die Arbeit mit der Datenbank-Interaktion etwas einfacher wird. Sie erleichtern Ihnen die Arbeit, wenn Sie wichtige Versionsänderungen in Ihrer Interaktionsebene vornehmen. Sie machen auch einige schwierige Aufgaben wie dynamisches Reporting etwas effizienter und einfacher zu handhaben. Ich werde an jedem Tag der Woche etwas einfacher sein.

Bei allem gibt es Kompromisse.

"Ansichten können und werden möglicherweise Ihre Leistung beeinträchtigen."

Wie ich in der Vergangenheit geschrieben habe, glaube ich daran, Kompromisse zu machen, solange Sie verstehen, was auf dem Tisch liegt. Es ist sehr wahrscheinlich, dass jemand an diesem Absatz vorbeikommt und einen Kommentar abgibt, dass Sie niemals eine Ansicht verwenden sollten, weil die Leistung beeinträchtigt ist. Ich stimme dir nicht zu. Sie sollten jedes Werkzeug in Ihrer Toolbox verwenden, wenn es sinnvoll ist. Sie verwenden keinen Hammer, um eine Schraube in eine Wand zu stecken, genauso wie Sie eine Ansicht nicht verwenden würden, wenn Sie wirklich einen Heap- / Speichertisch benötigen. Die Kehrseite ist die Entwicklungsfähigkeit für Ihre Anwendungen. Wenn es sinnvoll ist, Zeit, Mühe und Energie in Bezug auf die Leistung zu sparen, die Sie möglicherweise treffen, sollten Sie diese Entscheidung treffen. Bei der Entwicklung geht es nicht nur um die Leistung Ihrer Anwendungen, da es andere Aspekte wie Support, Time-to-Market und Gesamtwert Ihrer Zeit gibt.

Die Werkzeuge, mit denen ich in diesem Tutorial arbeite, sind ziemlich standard. Ich verwende phpMyAdmin für die Datenbankinteraktion zu Erklärungszwecken. Ich werde auch sehr rudimentäre Tabellenstrukturen verwenden, um die Erklärung zu vereinfachen. Ich erwarte nicht, dass diese Tabellenstrukturen jemals in einer Produktionsumgebung verwendet werden würden, da ich sie nur zur Veranschaulichung verwende.

Noch eine Anmerkung. Es gibt keinen richtigen oder falschen Weg, um eine Ansicht zu benennen. Ich benenne meine Ansichten jedoch mit der Syntax von view_ * primary_table * _ * what_the_view_is_used_for *, sofern ich nicht für Abwärtskompatibilitätsänderungen arbeite. Wenn ich also für meine Salesforce-Tabelle eine Ansicht für statistische Berichtszwecke erstellt habe, würde ich als Ansichtsnamen Folgendes angeben: view_salesforce_statistical_report. Das kann ziemlich lang sein und Sie haben nur 64 Zeichen, mit denen Sie arbeiten können. Denken Sie also daran. Es funktioniert für mich und meinen Stil, es kann für Sie nicht funktionieren.

"Ich werde nicht sagen, dass Ansichten Ihr Leben verändern werden, aber ich sage Ihnen, dass die Arbeit mit der Datenbank-Interaktion ein bisschen einfacher wird, damit Sie arbeiten können. Sie werden Ihre Arbeit etwas einfacher machen, wenn Sie größere Versionsänderungen vornehmen Ihre Interaktionsebene. Sie machen auch einige schwierige Aufgaben wie dynamisches Reporting etwas effizienter und einfacher zu handhaben. "


Definitionen: So definieren Sie eine Ansicht

Wie gesagt, eine Ansicht ist nur eine Abfrage. Beim Erstellen einer Ansicht müssen einige geringfügige Konfigurationen vorgenommen werden. Lassen Sie uns das zuerst besprechen. In phpMyAdmin wird auf der Tabellenseite "Browse" ein Link mit dem Namen "Create View" angezeigt..

Wenn Sie auf diesen Link klicken, sollten Sie etwas sehen, das folgendermaßen aussieht:

Hier, meine Freunde, geschieht die Magie. Es gibt nicht viel zu erklären auf der Seite, aber werfen wir einen Blick auf die Definitionen, die wir verstehen müssen, um eine Ansicht zu erstellen.

Zuerst gibt es "Ansicht erstellen", gefolgt von "ODER ERSETZEN". Wenn Sie auf die Schaltfläche ODER REPLACE klicken, wird genau so vorgegangen, wie Sie denken, dh eine vorhandene Ansicht wird überschrieben. Spaltennamen ist der Name der Spalten in Ihrer Tabelle. Jedes ist durch ein Komma getrennt, daher könnte es wie vorname, zweitername usw. aussehen. AS ist die Abfrage.

Es gibt zwei weitere Punkte, die erklärt werden müssen, aber die Konzepte sind nicht schwer. ALGORITHM hat die Auswahl zwischen undefined, merge und temporäre Tabelle. Wenn Sie bei einer Eins-zu-Eins-Beziehung "Zusammenführen" auswählen, wird die eingehende Abfrage mit der Ansicht kombiniert. Die Temp-Tabelle ist weniger effizient, aber wenn Sie keine Eins-zu-Eins-Beziehung verwenden, wie z. B. eine Aggregationsfunktion wie SUM (), oder wenn Sie bestimmte Schlüsselwörter wie GROUP BY oder HAVING oder UNION verwenden, müssen Sie den Temp-Tabellen-Algorithmus verwenden. Das heißt, Sie können es wie ich tun und den Algorithmus als "undefined" belassen, und MySQL wählt den besten zu verwendenden Algorithmus aus.

Schließlich haben wir die Optionen CASCADED CHECK OPTION und LOCAL CHECK. Über die Prüfoptionen wird MySQL angewiesen, die Sichtdefinition zu überprüfen, wenn die Abfrage eine Bedingung enthält, z. B. WHERE. Wenn die WHERE-Klausel Daten ausschließt, verhindert sie das Aktualisieren oder Einfügen der Zeilen, in denen sie ausgeschlossen werden sollen. Der LOCAL CHECK behandelt nur die von Ihnen definierte Sicht, wobei CASCADED CHECK für Ansichten gilt, die Sie aus anderen Ansichten definiert haben. Es wird die Überprüfung auch für diese kaskadieren.

Das ist eine kurze Zusammenfassung. Schauen wir uns einige Anwendungsfälle an, um sie in Aktion zu sehen und wo sie Ihre Entwicklungsanstrengungen unterstützen können.


Rückwärtskompatibilität: Für den Procrastinator

Ich habe es öfter erlebt, als ich es gerne erwähnen würde, wenn ich einen Tisch zur einmaligen Verwendung entwerfe, von dem ich glaube, dass er sich nicht zwangsläufig weiter normalisieren muss. Nehmen wir das Beispiel, das zuvor mit ein paar weiteren Datensätzen gezeigt wurde.

Offensichtlich lassen meine Normalisierungsfähigkeiten in diesem Beispiel zu wünschen übrig. Was ich wahrscheinlich hätte tun sollen, als ich diese Tabelle erstellt habe, hatte eine separate Tabelle für Adressen und dann einfach eine address_id in meiner Außendiensttabelle. Das Problem ist, sobald ich zu einer Datenbankänderung übergegangen bin, muss ich meine logische Interaktionsebene erneut durchlaufen und zahlreiche Abfrageänderungen vornehmen. Anstatt so viel Arbeit zu erledigen, warum sollte man nicht einen Blick zur Rettung kommen lassen.

Zuerst nehmen wir die Änderung an meiner Tabellenstruktur vor. Ich kopiere meine Tabellenstruktur und Daten in meine neue Tabelle, Adressen und mache die Tabelle vernünftig, indem ich beispielsweise address_id hinzufüge und die nicht benötigte Struktur entferne:

Dann muss ich nur die fehlerhaften Spalten löschen und meine address_id zurück zu meiner Verkaufstabelle hinzufügen.

Dies ist eine ziemlich häufige Änderung, die Sie halbregelmäßig vornehmen, obwohl sie eher vereinfachend ist. Sie finden heraus, dass Sie etwas aufgrund einer neuen Funktion normalisieren können. In diesem Fall können wir unsere Adressen für Kunden oder für andere Mitarbeiter oder für was auch immer wir Adressen speichern, wiederverwenden. Diese Arbeit ist nicht so schwierig, aber je nach der Wiederverwendung Ihrer Abfrage kann es sehr viel umfangreicher sein, alle Orte zu finden, an denen Sie unsere alte sales_force-Tabelle aufgerufen haben. In kommt ein Blick.

Anstatt unseren Code jetzt noch einmal durchzugehen und auf einen normalen Release-Zyklus zu warten, können wir eine Ansicht erstellen, um die alte Funktionalität zu erhalten. Ich habe den Namen unserer sales_force-Tabelle in sales_force_normalized geändert:

Jetzt können wir unsere Ansicht erstellen, um die Abwärtskompatibilität zu wahren:

Und wir sind abwärtskompatibel mit der zusätzlichen Arbeit, eine Abfrage zu erstellen, die in MySQL liegt:

Auch wenn ich einen neuen Verkäufer eingebe, spiegelt meine Ansicht die Änderung wider:

Und presto:

Ungefähr zwei Minuten Arbeit, um unsere Abwärtskompatibilität zu unserer vorherigen Datenstruktur aufrechtzuerhalten. Diese Methode hat Nachteile, da Sie für Ihre Ansicht keinen Index definieren können. Dies ist wichtig, wenn Sie Ansichten kaskadieren. Außerdem müssen Sie Ihre Abfragen für INSERT, DELETE und UPDATE noch ändern. Dies erspart Ihnen jedoch einige Arbeit. Ihre Leistung könnte etwas sinken, aber als Stop Gap gibt es keine einfachere Möglichkeit, eine Änderung an Ihrer Datenstruktur vorzunehmen, um Ihre Codebasis in diese Änderung zu integrieren. Ihre Fragen in Ihrer Logikebene bleiben davon unberührt, da sie, soweit sie wissen, auf die Originaltabelle schauen.


Komplexe Abfragen: Das Schwerfällige machen

Nun, da wir unseren Proof of Concept unter den Gürteln haben, wollen wir uns eine andere Verwendung ansehen. Ich habe eine weitere Tabelle erstellt, um die Verkaufsdaten aus meiner Salesforce-Tabelle zu erfassen, und sie mit zufälligen Informationen gefüllt. Es sieht aus wie das:

Es ist eine extrem vereinfachte Tabelle, um den Umsatz der Salesforce zur Illustration zu erfassen. Es gibt immer Dinge, die wir zur Messung an einem solchen Tisch extrahieren möchten. Ich möchte wahrscheinlich den Gesamtumsatz wissen. Ich würde wahrscheinlich den Gesamtumsatz pro Person wissen wollen. Ich möchte vielleicht auch den Rang der Verkaufsleistung kennen. Ich könnte Abfragen in meine Datenbanklogik schreiben, um diese jeweils auszuführen, wenn ich sie brauche, oder ich könnte einfach eine Ansicht schreiben, um die Daten nach Bedarf zu erfassen. Da dies ein Tutorial über Ansichten ist, denke ich, ist die Wahl an dieser Stelle ziemlich einfach, welche Taktik zu ergreifen ist.

Beginnen wir mit der Bewertung des Gesamtumsatzes und anderer relevanter Informationen:

Was gibt uns einen Blick auf:

Ich habe auch die Abfragezeit für dieses Thema mit einbezogen, da 200 Datensätze betrachtet werden, dies ist zwar sehr schnell, aber die Leistung variiert. Beachten Sie, dass ich die CHECK-Funktionen nicht verwende, weil ich die Informationen in einer WHERE-Klausel nicht diskriminiere. Nun, da wir diese Informationen ordentlich verpackt haben, müssen wir lediglich unseren Berichterstattungsmechanismus in unsere Logik integrieren.

Diese Informationen zu erhalten ist nicht so schwer. Gehen wir noch einen Schritt weiter und verwenden Sie die GROUP BY-Funktion und eine Join-Funktion gegen die Salesforce. Auch hier verwende ich vereinfachte Abfragen zur Veranschaulichung. In diesem Fall möchten wir die gleichen Informationen erhalten, die wir vom Gesamtumsatz hatten, diesmal jedoch von unserem individuellen Verkäufer.

Was gibt uns einen Blick auf:

Am Ende ganz einfach, um diese Werte aus Ihrer Datenbank zu holen. Schauen wir uns ein weiteres Beispiel an, in dem die beiden Ansichten kombiniert werden. Ich möchte die Gesamtwerte mit der Person vergleichen, und wir erstellen eine Ansicht von zwei Ansichten:

Was gibt uns einen Blick auf:


Fazit

Ein weiterer Vorteil von Ansichten ist, dass sie Ihren Anwendungen eine weitere Sicherheitsstufe bieten. Sie machen Ihre Tabellenstruktur nicht für Ihre Anwendung verfügbar. Stattdessen legen Sie etwas frei, das nicht wirklich existiert, außer als Pseudotabelle. Ich würde eine Ansicht nicht als Best Practice bezeichnen und sie in erster Linie zum Schreiben sicherer Anwendungen verwenden, aber ich würde sie als zusätzlichen Vorteil betrachten.

Ich benutze Ansichten in begrenztem Umfang. Wo ich Ansichten verwende, werden wie oben gezeigt, insbesondere in den Berichterstattungsmechanismen in meinen Anwendungen. Eine Abfrage zu schreiben, um das schwere Heben für mich durchzuführen, ist viel einfacher als das Schreiben der Logik um schwierigere Abfragen. Ich nehme von Zeit zu Zeit ein bisschen Leistung bei meiner Leistung, die ich durch die Optimierung der ursprünglichen Datenstruktur überwinden kann. Ich muss noch einen Showstopper haben, aber der Tag ist jung. Vielen Dank fürs Lesen.