SQL-Handbuch: Besseres Schreiben von Abfragen (Teil 1)

Erfahren Sie mehr über Antimuster, Ausführungspläne, Zeitkomplexität, Abfrageoptimierung und SQL-Optimierung

Structured Query Language (SQL) ist eine unverzichtbare Fähigkeit in der Informatikbranche, und im Allgemeinen ist das Erlernen dieser Fähigkeit relativ einfach. Die meisten Leute vergessen jedoch, dass es bei SQL nicht nur um das Schreiben von Abfragen geht, sondern nur um den ersten Schritt in die Zukunft. Ganz anders ist es, die Abfrageleistung sicherzustellen oder den Kontext abzugleichen, in dem Sie arbeiten.

Aus diesem Grund erhalten Sie in diesem SQL-Handbuch einen kleinen Überblick über einige der Schritte, die Sie zur Bewertung Ihrer Abfrage ausführen können:

• Zunächst erhalten Sie einen kurzen Überblick über die Bedeutung des SQL-Lernens für die Arbeit im Bereich der Datenwissenschaft.
• Als Nächstes lernen Sie zunächst, wie Sie SQL-Abfragen verarbeiten und ausführen, um zu verstehen, wie wichtig es ist, Qualitätsabfragen zu erstellen. Insbesondere werden Sie sehen, dass die Anfrage analysiert, neu geschrieben, optimiert und schließlich ausgewertet wird.
• In diesem Sinne werden Sie nicht nur zu einigen der Antimuster von Abfragen übergehen, die Anfänger beim Schreiben von Abfragen stellen, sondern auch mehr über Alternativen und Lösungen für diese möglichen Fehler erfahren. Darüber hinaus erfahren Sie mehr über den satzbasierten Abfrageansatz.
• Sie werden auch feststellen, dass diese Antimuster auf Leistungsproblemen beruhen und dass Sie zusätzlich zum „manuellen“ Ansatz zur Verbesserung von SQL-Abfragen Ihre Abfragen mithilfe einiger anderer Tools, die Ihnen beim Anzeigen des Abfrageplans helfen, strukturierter und eingehender analysieren können. Und
• Sie lernen kurz die zeitliche Komplexität und die große O-Notation kennen, um sich rechtzeitig vor der Ausführung der Anforderung ein Bild von der Komplexität des Ausführungsplans zu machen.
• Sie erfahren kurz, wie Sie Ihre Abfrage optimieren.

Warum sollten Sie SQL lernen, um mit Daten zu arbeiten?

SQL ist alles andere als tot: Dies ist eine der gefragtesten Fähigkeiten, die Sie in Stellenbeschreibungen aus der Datenverarbeitungs- und Analysebranche finden, unabhängig davon, ob Sie sich für Datenanalyse, Dateningenieur, Datenspezialist oder eine andere Rolle bewerben. Dies wird von 70% der Befragten der O 'Reilly Data Science-Gehaltsumfrage für 2016 bestätigt, die angeben, dass sie SQL in ihrem beruflichen Kontext verwenden. Darüber hinaus hebt sich SQL in dieser Umfrage von den Programmiersprachen R (57%) und Python (54%) ab.

Sie bekommen das Bild: SQL ist eine notwendige Fähigkeit, wenn Sie daran arbeiten, einen Job in der IT-Branche zu bekommen.

Nicht schlecht für eine Sprache, die in den frühen 1970ern entwickelt wurde, oder?

Aber warum wird es so oft verwendet? Und warum ist er nicht gestorben, obwohl er so lange existiert hat?

Es gibt mehrere Gründe: Einer der ersten Gründe könnte sein, dass Unternehmen Daten hauptsächlich in relationalen Datenbankverwaltungssystemen (RDBMS) oder in relationalen Datenflussmanagementsystemen (RDSMS) speichern und SQL für den Zugriff auf diese Daten erforderlich ist. SQL ist eine Verkehrssprache für Daten: Es ermöglicht die Interaktion mit fast jeder Datenbank oder sogar die Erstellung eigener Datenbanken vor Ort!

Wenn dies immer noch nicht ausreicht, denken Sie daran, dass es einige SQL-Implementierungen gibt, die zwischen Anbietern nicht kompatibel sind und nicht unbedingt den Standards entsprechen. Kenntnisse in Standard-SQL sind daher eine Voraussetzung, um sich in der Branche (Informatik) zurechtzufinden.

Darüber hinaus kann man mit Sicherheit sagen, dass auch neuere Technologien SQL beigetreten sind, z. B. Hive, eine SQL-ähnliche Abfragesprachenschnittstelle zum Abfragen und Verwalten großer Datenmengen, oder Spark SQL, mit dem SQL-Abfragen ausgeführt werden können. Auch hier unterscheidet sich das SQL, das Sie dort finden, von dem Standard, den Sie lernen könnten, aber die Lernkurve wird viel einfacher.

Wenn Sie einen Vergleich anstellen möchten, betrachten Sie ihn als Lernen der linearen Algebra: Wenn Sie all diese Anstrengungen in dieses eine Fach gesteckt haben, wissen Sie, dass Sie damit auch maschinelles Lernen beherrschen können!

Kurz gesagt, aus diesem Grund sollten Sie diese Abfragesprache lernen:

• Es ist ziemlich leicht zu lernen, auch für Anfänger. Die Lernkurve ist recht einfach und schrittweise, sodass Sie so schnell wie möglich Abfragen schreiben.
• Es folgt dem Prinzip „einmal lernen, überall anwenden“, also ist dies eine großartige Investition Ihrer Zeit!
• Dies ist eine großartige Ergänzung zu Programmiersprachen. In einigen Fällen ist das Schreiben einer Abfrage sogar dem Schreiben von Code vorzuziehen, da dies effizienter ist!
• ...

Worauf warten Sie noch? :) :)

SQL-Verarbeitung und Abfrageausführung

Um die Leistung Ihrer SQL-Abfrage zu verbessern, müssen Sie zunächst wissen, was im Inneren passiert, wenn Sie auf eine Verknüpfung klicken, um die Abfrage auszuführen.

Zunächst wird die Anforderung in einen Analysebaum analysiert. Die Anforderung wird auf Übereinstimmung mit syntaktischen und semantischen Anforderungen analysiert. Der Parser erstellt eine interne Darstellung der Eingabeanforderung. Diese Ausgabe wird dann an den Umschreibemechanismus übertragen.

Dann muss der Optimierer den optimalen Ausführungs- oder Abfrageplan für die angegebene Abfrage finden. Der Ausführungsplan bestimmt genau, welcher Algorithmus für jede Operation verwendet wird und wie Operationen koordiniert werden.

Um den optimalsten Ausführungsplan zu finden, listet der Optimierer alle möglichen Implementierungspläne auf, ermittelt die Qualität oder die Kosten jedes Plans, empfängt Informationen über den aktuellen Status der Datenbank und wählt dann den besten als endgültigen Implementierungsplan aus. Da Abfrageoptimierer unvollständig sein können, müssen Benutzer und Datenbankadministratoren die vom Optimierer erstellten Pläne manchmal manuell überprüfen und optimieren, um die Leistung zu verbessern.

Jetzt fragen Sie sich wahrscheinlich, was als „guter Abfrageplan“ angesehen wird.

Wie Sie bereits gelesen haben, spielt die Qualität der Kosten eines Plans eine wichtige Rolle. Insbesondere sind Dinge wie die Anzahl der zur Auswertung des Plans erforderlichen Festplatten-E / A, die Kosten der CPU des Plans und die Gesamtantwortzeit, die der Datenbankclient beobachten kann, sowie die Gesamtausführungszeit wichtig. Hier entsteht das Konzept der Zeitkomplexität. Sie werden später mehr darüber erfahren.

Anschließend wird der ausgewählte Abfrageplan ausgeführt, vom Systemausführungsmechanismus ausgewertet und die Abfrageergebnisse zurückgegeben.

SQL-Abfragen schreiben

Aus dem vorherigen Abschnitt ist möglicherweise nicht klar geworden, dass sich das Prinzip von Garbage In, Garbage Out (GIGO) natürlich in der Verarbeitung und Ausführung einer Abfrage manifestiert: Derjenige, der die Abfrage formuliert, verfügt auch über Schlüssel für die Leistung Ihrer SQL-Abfragen. Wenn der Optimierer eine schlecht formulierte Anfrage erhält, kann er genauso viel tun ...

Dies bedeutet, dass Sie beim Schreiben einer Anfrage einige Dinge tun können. Wie Sie bereits in der Einleitung gesehen haben, gibt es hier zwei Verantwortlichkeiten: Es geht nicht nur darum, Abfragen zu schreiben, die einem bestimmten Standard entsprechen, sondern auch darum, Ideen zu sammeln, wo Leistungsprobleme in Ihrer Abfrage verborgen sein könnten.

Ein idealer Ausgangspunkt besteht darin, in Ihren Abfragen an „Stellen“ zu denken, an denen Probleme auftreten können. Im Allgemeinen gibt es vier Schlüsselwörter, bei denen Neulinge mit Leistungsproblemen rechnen können:

• Bedingung WHERE ;
• Alle Schlüsselwörter INNER JOIN oder LEFT JOIN ; Und auch,
• Zustand haben;

Natürlich ist dieser Ansatz einfach und naiv, aber für Anfänger sind diese Punkte hervorragende Hinweise, und man kann mit Sicherheit sagen, dass beim ersten Start Fehler an diesen Stellen auftreten und seltsamerweise auch dort, wo es schwer zu bemerken ist.

Sie sollten jedoch auch verstehen, dass Leistung etwas ist, das sinnvoll werden sollte. Nur zu sagen, dass diese Sätze und Schlüsselwörter schlecht sind, ist jedoch nicht das, was Sie brauchen, wenn Sie über die SQL-Leistung nachdenken. Eine HAVING oder HAVING in einer Anfrage zu haben, bedeutet nicht unbedingt, dass es sich um eine schlechte Anfrage handelt ...

Im nächsten Abschnitt erfahren Sie mehr über Antimuster und alternative Ansätze zum Erstellen Ihrer Abfrage. Diese Tipps und Tricks dienen als Leitfaden. Wie und ob Sie Ihre Anfrage wirklich neu schreiben müssen, hängt unter anderem von der Datenmenge, der Datenbank und der Häufigkeit ab, mit der Sie die Anfrage abschließen müssen. Es hängt ganz vom Zweck Ihrer Anfrage ab und es ist entscheidend, Vorkenntnisse über die Datenbank zu haben, mit der Sie arbeiten werden!

1. Rufen Sie nur die erforderlichen Daten ab

Die Schlussfolgerung „Je mehr Daten, desto besser“ muss beim Schreiben von SQL nicht beachtet werden: Sie riskieren nicht nur, verwirrt zu werden, wenn Sie mehr Daten abrufen, als Sie wirklich benötigen, sondern auch die Leistung kann darunter leiden, dass Ihre Abfrage zu viele Daten empfängt.

Aus diesem Grund sollten Sie in der Regel auf die SELECT , die DISTINCT SELECT und die LIKE Anweisung achten.

SELECT

Das erste, was Sie bereits beim Schreiben einer Abfrage überprüfen können, ist, ob die SELECT so kompakt wie möglich ist. Das Ziel hier sollte sein, unnötige Spalten aus SELECT zu entfernen. Auf diese Weise zwingen Sie sich, nur Daten abzurufen, die Ihrem Abfragezweck dienen.

Wenn Sie Unterabfragen mit EXISTS korreliert haben, sollten Sie versuchen, eine Konstante in der SELECT dieser Unterabfrage zu verwenden, anstatt den Wert der tatsächlichen Spalte auszuwählen. Dies ist besonders praktisch, wenn Sie nur nach Existenz suchen.

Denken Sie daran, dass eine korrelierte Unterabfrage eine Unterabfrage ist, die Werte aus einer externen Abfrage verwendet. Und beachten Sie, dass NULL in diesem Zusammenhang zwar als „Konstante“ NULL kann, dies jedoch sehr verwirrend ist!

Betrachten Sie das folgende Beispiel, um zu verstehen, was unter Verwendung einer Konstante zu verstehen ist:

 SELECT driverslicensenr, name FROM Drivers WHERE EXISTS (SELECT '1' FROM Fines WHERE fines.driverslicensenr = drivers.driverslicensenr); 

Tipp: Es ist hilfreich zu wissen, dass eine korrelierte Unterabfrage nicht immer eine gute Idee ist. Sie können sie jederzeit INNER JOIN , indem Sie sie beispielsweise mit INNER JOIN :

 SELECT driverslicensenr, name FROM drivers INNER JOIN fines ON fines.driverslicensenr = drivers.driverslicensenr; 

Operation DISTINCT

Die SELECT DISTINCT verwendet, um nur unterschiedliche Werte zurückzugeben. DISTINCT ist ein Punkt, der nach Möglichkeit unbedingt vermieden werden sollte. Wie in anderen Beispielen erhöht sich die Ausführungszeit nur, wenn dieser Satz zur Anforderung hinzugefügt wird. Daher ist es immer hilfreich zu prüfen, ob Sie diese DISTINCT Operation wirklich benötigen, um die gewünschten Ergebnisse zu erzielen.

LIKE Aussage

Bei Verwendung des Operators LIKE in einer Abfrage wird der Index nicht verwendet, wenn das Muster mit % oder _ beginnt. Dadurch wird verhindert, dass die Datenbank den Index verwendet (falls vorhanden). Unter einem anderen Gesichtspunkt kann natürlich auch argumentiert werden, dass diese Art von Anforderung möglicherweise dazu führt, dass zu viele Datensätze abgerufen werden, die nicht unbedingt den Zweck der Anforderung erfüllen.

Wenn Sie die in der Datenbank gespeicherten Daten kennen, können Sie eine Vorlage formulieren, die alle Daten korrekt filtert, um nur die Zeilen zu finden, die für Ihre Abfrage wirklich wichtig sind.

2. Begrenzen Sie Ihre Ergebnisse

Wenn Sie das Filtern Ihrer SELECT nicht vermeiden können, können Sie Ihre Ergebnisse auf andere Weise einschränken. Hier kommen Ansätze wie die LIMIT und Datentypkonvertierungen ins LIMIT .

ROWNUM LIMIT ROWNUM und ROWNUM

Sie können Abfragen LIMIT oder TOP Anweisungen hinzufügen, um die maximale Anzahl von Zeilen für die Ergebnismenge anzugeben. Hier einige Beispiele:

  SELECT TOP 3 * FROM Drivers; 

Beachten Sie, dass Sie optional PERCENT angeben PERCENT , wenn Sie beispielsweise die erste SELECT TOP 50 PERCENT * mit SELECT TOP 50 PERCENT * .

 SELECT driverslicensenr, name FROM Drivers LIMIT 2; 

Alternativ können Sie die ROWNUM hinzufügen, die der Verwendung von LIMIT in der Abfrage entspricht:

 SELECT * FROM Drivers WHERE driverslicensenr = 123456 AND ROWNUM <= 3; 

Datentypkonvertierungen

Die effektivsten sollten immer verwendet werden, d.h. kleinste Datentypen. Es besteht immer ein Risiko, wenn Sie einen großen Datentyp bereitstellen, während ein kleinerer Datentyp ausreicht.

Wenn Sie der Abfrage jedoch eine Datentypkonvertierung hinzufügen, erhöht sich nur die Ausführungszeit.

Eine Alternative besteht darin, die Datentypkonvertierung so weit wie möglich zu vermeiden. Beachten Sie auch, dass es nicht immer möglich ist, die Datentypkonvertierung aus Abfragen zu entfernen oder zu überspringen. Sie sollten jedoch immer versuchen, sie einzuschließen, und die Auswirkungen des Hinzufügens überprüfen, bevor Sie die Abfrage ausführen.

3. Machen Sie Abfragen nicht komplizierter als sie sein sollten

Datentypkonvertierungen führen Sie zu folgendem Punkt: Sie sollten Ihre Abfragen nicht übermäßig gestalten. Versuchen Sie, sie einfach und effektiv zu machen. Dies mag zu einfach oder zu dumm erscheinen, um ein Hinweis zu sein, hauptsächlich weil die Anforderungen komplex sein können.

In den in den folgenden Abschnitten genannten Beispielen werden Sie jedoch feststellen, dass Sie einfache Abfragen problemlos komplexer gestalten können, als sie sein sollten.

OR Operator

Wenn Sie den Operator OR in Ihrer Abfrage verwenden, verwenden Sie höchstwahrscheinlich keinen Index.

Denken Sie daran, dass ein Index eine Datenstruktur ist, die die Suche nach Daten in einer Datenbanktabelle beschleunigt, aber teuer ist: Zusätzliche Datensätze und zusätzlicher Speicherplatz sind erforderlich, um die Indexdatenstruktur aufrechtzuerhalten. Indizes werden verwendet, um schnell nach Daten zu suchen oder zu suchen, ohne bei jedem Zugriff auf die Datenbanktabelle jede Zeile in der Datenbank durchsuchen zu müssen. Indizes können mithilfe einer oder mehrerer Spalten in einer Datenbanktabelle erstellt werden.

Wenn Sie keine in der Datenbank enthaltenen Indizes verwenden, dauert die Ausführung Ihrer Abfrage zwangsläufig länger. Aus diesem Grund sollten Sie in Ihrer Abfrage nach Alternativen zur Verwendung des Operators OR suchen.

Betrachten Sie die folgende Abfrage:

 SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr = 123456 OR driverslicensenr = 678910 OR driverslicensenr = 345678; 

Der Bediener kann ersetzt werden durch:

Bedingung mit IN ; oder

 SELECT driverslicensenr, name FROM Drivers WHERE driverslicensenr IN (123456, 678910, 345678); 

Zwei SELECT mit UNION .

Tipp: Hier müssen Sie darauf achten, die unnötige UNION Operation nicht zu verwenden, da Sie dieselbe Tabelle mehrmals anzeigen. Gleichzeitig sollten Sie verstehen, dass sich die Ausführungszeit erhöht, wenn Sie UNION in Ihrer Abfrage verwenden. Alternativen zur UNION Operation: Formulieren Sie die Abfrage neu, sodass alle Bedingungen in einer einzigen SELECT , oder verwenden Sie OUTER JOIN anstelle von UNION .

Tipp: Beachten Sie, dass OR - und die anderen Operatoren, die in den folgenden Abschnitten erwähnt werden - höchstwahrscheinlich keinen Index verwenden, die Indexsuche jedoch nicht immer vorzuziehen ist!

NOT Betreiber

Wenn Ihre Abfrage einen NOT Operator enthält, wird der Index wahrscheinlich nicht wie beim OR Operator verwendet. Dies wird Ihre Anfrage zwangsläufig verlangsamen. Wenn Sie nicht wissen, was hier gemeint ist, berücksichtigen Sie die folgende Abfrage:

 SELECT driverslicensenr, name FROM Drivers WHERE NOT (year > 1980); 

Diese Anforderung wird sicherlich langsamer ausgeführt als erwartet, hauptsächlich weil sie viel komplexer formuliert ist als sie sein kann: In solchen Fällen ist es am besten, nach einer Alternative zu suchen. Ersetzen Sie NOT Vergleichsoperatoren wie > , <> oder !> . Das obige Beispiel kann tatsächlich umgeschrieben werden und ungefähr so ​​aussehen:

 SELECT driverslicensenr, name FROM Drivers WHERE year <= 1980; 

Es sieht schon besser aus, oder?

AND Operator

Der AND Operator ist ein weiterer Operator, der keinen Index verwendet und eine Abfrage verlangsamen kann, wenn sie wie im folgenden Beispiel zu komplex und ineffizient verwendet wird:

 SELECT driverslicensenr, name FROM Drivers WHERE year >= 1960 AND year <= 1980; 

Es ist besser, diese Abfrage mit der BETWEEN Anweisung neu zu schreiben:

 SELECT driverslicensenr, name FROM Drivers WHERE year BETWEEN 1960 AND 1980; 

ANY und ALL Operatoren

Darüber hinaus sollten Sie mit den Operatoren ANY und ALL vorsichtig sein, da der Index nicht verwendet wird, wenn Sie sie in Ihre Abfragen aufnehmen. Hier sind alternative Aggregationsfunktionen wie MIN oder MAX nützlich.

Tipp: In Fällen, in denen Sie die vorgeschlagenen Alternativen verwenden, sollten Sie sich bewusst sein, dass alle Aggregationsfunktionen wie SUM , AVG , MIN , MAX über viele Zeilen zu einer langen Abfrage führen können. In solchen Fällen können Sie versuchen, die Anzahl der zu verarbeitenden Zeilen zu minimieren oder diese Werte vorab zu berechnen. Wieder einmal sehen Sie, dass es wichtig ist, über Ihre Umgebung, Ihren Zweck der Anfrage, ... Bescheid zu wissen, wenn Sie sich für eine Anfrage entscheiden!

Säulen unter Bedingungen isolieren

In Fällen, in denen eine Spalte in einer Berechnung oder in einer Skalarfunktion verwendet wird, wird der Index nicht verwendet. Eine mögliche Lösung wäre, einfach eine bestimmte Spalte auszuwählen, damit sie nicht mehr Teil der Berechnung oder Funktion ist. Betrachten Sie das folgende Beispiel:

 SELECT driverslicensenr, name FROM Drivers WHERE year + 10 = 1980; 

Es sieht lustig aus, oder? Versuchen Sie stattdessen, die Berechnung zu überarbeiten, und schreiben Sie die Abfrage folgendermaßen neu:

 SELECT driverslicensenr, name FROM Drivers WHERE year = 1970; 

4. Mangel an roher Gewalt

Dieser letzte Tipp bedeutet, dass Sie nicht versuchen sollten, die Anforderung zu stark einzuschränken, da dies die Leistung beeinträchtigen kann. Dies gilt insbesondere für Joins und für die HAVING-Klausel.

Tabellenreihenfolge in Joins

Beim Verbinden von zwei Tabellen kann es wichtig sein, die Reihenfolge der Tabellen im Join zu berücksichtigen. Wenn Sie feststellen, dass eine Tabelle erheblich größer als die andere ist, müssen Sie die Abfrage möglicherweise neu schreiben, damit die größte Tabelle als letzte im Join platziert wird.

Übermäßige Verbindungsbedingungen

Wenn Sie SQL-Verbindungen zu viele Bedingungen hinzufügen, müssen Sie einen bestimmten Pfad auswählen. Es kann jedoch sein, dass dieser Pfad nicht immer effizienter ist.

Zustand haben

Die HAVING wurde ursprünglich zu SQL hinzugefügt, da das WHERE Schlüsselwort nicht mit Aggregatfunktionen verwendet werden konnte. HAVING normalerweise mit der GROUP BY , um Gruppen zurückgegebener Zeilen auf diejenigen zu beschränken, die bestimmte Bedingungen erfüllen. Wenn diese Bedingung jedoch in der Abfrage verwendet wird, wird der Index nicht verwendet, was, wie Sie bereits wissen, dazu führen kann, dass die Abfrage tatsächlich nicht so gut funktioniert.

Wenn Sie nach einer Alternative suchen, verwenden Sie die WHERE .

Berücksichtigen Sie die folgenden Fragen:

 SELECT state, COUNT(*) FROM Drivers WHERE state IN ('GA', 'TX') GROUP BY state ORDER BY state 

 SELECT state, COUNT(*) FROM Drivers GROUP BY state HAVING state IN ('GA', 'TX') ORDER BY state 

Die erste Abfrage verwendet die WHERE , um die Anzahl der Zeilen zu begrenzen, die zusammengefasst werden müssen, während die zweite Abfrage alle Zeilen in der Tabelle HAVING und dann HAVING , um die berechneten Beträge zu verwerfen. In solchen Fällen ist die Option WHERE eindeutig besser, da Sie keine Ressourcen verschwenden.

Es ist ersichtlich, dass es nicht darum geht, die Ergebnismenge zu begrenzen, sondern darum, die mittlere Anzahl von Datensätzen in der Abfrage zu begrenzen.

Es ist zu beachten, dass der Unterschied zwischen den beiden Bedingungen darin besteht, dass die WHERE eine Bedingung für einzelne Zeilen HAVING , während die HAVING eine Bedingung für Aggregationen oder Auswahlergebnisse einführt, wobei ein Ergebnis wie MIN , MAX , SUM , ... war aus mehreren Zeilen erstellt.

Sie sehen, Qualitätsbewertung, Schreiben und Umschreiben von Anfragen sind keine leichte Aufgabe, da sie so produktiv wie möglich sein sollten. Die Verhinderung von Antimustern und die Berücksichtigung alternativer Optionen sind ebenfalls Teil der Verantwortung beim Schreiben von Abfragen, die in einem professionellen Umfeld an Datenbanken ausgeführt werden müssen.

Diese Liste war nur eine kleine Übersicht über einige Antimuster und Tipps, von denen ich hoffe, dass sie Anfängern helfen. Wenn Sie sich ein Bild davon machen möchten, welche älteren Entwickler die häufigsten Anti-Patterns betrachten, lesen Sie diese Diskussion .

Set-basierte versus prozedurale Ansätze zum Schreiben von Abfragen

Die oben genannten Antimuster implizierten, dass sie tatsächlich auf einen Unterschied in den satzbasierten und prozeduralen Ansätzen zur Erstellung Ihrer Abfragen zurückzuführen sind.

Der prozedurale Ansatz für Abfragen ist dem Programmieren sehr ähnlich: Sie teilen dem System mit, was zu tun ist und wie es zu tun ist.

Ein Beispiel hierfür sind übermäßige Bedingungen in Verbindungen oder Fällen, in denen Sie die HAVING Bedingungen missbrauchen, wie in den obigen Beispielen, in denen Sie eine Datenbank abfragen, indem Sie eine Funktion ausführen und dann eine andere Funktion aufrufen, oder wenn Sie eine Logik verwenden, die Bedingungen, Schleifen und benutzerdefinierte Funktionen enthält ( UDF), Cursor, ... um das Endergebnis zu erhalten. Bei diesem Ansatz fordern Sie häufig eine Teilmenge der Daten an, fordern dann eine weitere Teilmenge der Daten an und so weiter.

Es ist nicht überraschend, dass dieser Ansatz häufig als "Schritt-für-Schritt" - oder "Zeile für Zeile" -Abfrage bezeichnet wird.

Ein anderer Ansatz ist ein satzbasierter Ansatz, bei dem Sie einfach angeben, was zu tun ist. Ihre Aufgabe besteht darin, die Bedingungen oder Anforderungen für die Ergebnismenge anzugeben, die Sie von der Abfrage erhalten möchten. Sie überlassen die Art und Weise, wie Ihre Daten abgerufen werden, den internen Mechanismen, die die Implementierung der Abfrage bestimmen: Sie lassen das Datenbankmodul die besten Algorithmen oder Verarbeitungslogiken bestimmen, um Ihre Abfrage auszuführen.

Da SQL satzbasiert ist, ist es nicht verwunderlich, dass dieser Ansatz effizienter als prozedural ist, und es wird auch erklärt, warum SQL in einigen Fällen schneller als Code ausgeführt werden kann.

Beratung ist ein satzbasierter Ansatz für die Abfrage, den die meisten führenden Arbeitgeber in der Informationstechnologiebranche von Ihnen verlangen! Es ist oft notwendig, zwischen diesen beiden Arten von Ansätzen zu wechseln.

Bitte beachten Sie, dass Sie, wenn Sie jemals eine Verfahrensanforderung benötigen, in Betracht ziehen sollten, diese umzuschreiben oder umzugestalten.

Der nächste Teil behandelt die Plan- und Abfrageoptimierung.