Messung der Komplexität von SQL-Anweisungen

Question

Die Komplexität von Methoden in den meisten Programmiersprachen kann in zyklomatischer Komplexität mit statischen Quellcodeanalysatoren gemessen werden. Gibt es eine ähnliche Metrik zur Messung der Komplexität einer SQL-Abfrage?

Es ist einfach genug, um die Zeit zu messen, die eine Abfrage benötigt, um zurückzukehren, aber was, wenn ich nur in der Lage sein möchte zu quantifizieren, wie kompliziert eine Abfrage ist?

[Bearbeiten/Hinweis] Während der Ausführungsplan ist nützlich, das ist nicht unbedingt, was ich in diesem Fall zu identifizieren versuche. Ich suche nicht, wie schwierig es für den Server ist, die Abfrage auszuführen, ich suche nach einer Metrik, die angibt, wie schwierig es für den Entwickler war, die Abfrage zu schreiben, und wie wahrscheinlich es ist, einen Fehler zu enthalten.

[Edit/Note 2] Zugegebenermaßen gibt es Zeiten, in denen die Messung der Komplexität nicht sinnvoll ist, aber es gibt auch Zeiten, in denen dies der Fall ist. Weitere Informationen zu diesem Thema finden Sie unter this question.

Answer 1

Gemeinsame Maße der Softwarekomplexität sind Cyclomatic Complexity (ein Maß dafür, wie kompliziert der Kontrollfluss ist) und Halstead complexity (ein Maß für die Komplexität der Arithmetik).

Der "Kontrollfluss" in einer SQL-Abfrage bezieht sich am besten auf die Operatoren "and" und "or" in der Abfrage.

Die "Rechenkomplexität" bezieht sich am besten auf Operatoren wie SUM oder implizite JOINS.

Sobald Sie entschieden haben, wie Sie jede Syntaxeinheit einer SQL-Abfrage kategorisieren, ob es sich um "Kontrollfluss" oder "Berechnung" handelt, können Sie direkt Cyclomatic- oder Halstead-Messungen berechnen.

Was der SQL-Optimierer mit Abfragen tut denken ist absolut irrelevant. Der Zweck von Komplexitätsmaßnahmen besteht darin, zu charakterisieren, wie schwer es für eine Person ist, die Abfrage zu verstehen, und nicht, wie effizient sie bewertet werden kann.

In ähnlicher Weise sollte das, was die DDL sagt oder ob Views involviert sind oder nicht, nicht in solche Komplexitätsmaßnahmen einbezogen werden. Die Annahme hinter diesen Metriken ist, dass die Komplexität von Maschinerie innerhalb einer gebrauchten Abstraktion nicht interessant ist, wenn man sie einfach aufruft, weil vermutlich diese Abstraktion etwas, was der Kodierer gut versteht. Das ist der Grund, warum Halstead- und Cyclomatic-Messungen keine aufgerufenen Subroutinen in ihrer Zählung enthalten, und ich denke, Sie können einen guten Fall machen, dass Ansichten und DDL-Informationen diese "aufgerufenen" Abstraktionen sind.

Schließlich, wie perfekt richtig oder wie falsch diese Komplexitätszahlen sind, spielt keine große Rolle, solange sie etwas Wahrheit über die Komplexität widerspiegeln und man sie relativ zueinander vergleichen kann. Auf diese Weise können Sie auswählen, welche SQL-Fragmente die komplexesten sind, also sortieren Sie sie alle und konzentrieren Sie sich auf die komplexesten Tests.

Answer 2

SQL-Abfragen sind eher deklarativ als prozedural: Sie geben nicht an, wie sie ihr Ziel erreichen sollen. Die SQL-Engine erstellt einen prozeduralen Angriffsplan, und das ist ein guter Ort, um nach Komplexität zu suchen. Versuchen Sie, die Ausgabe der Anweisung EXPLAIN (oder EXPLAIN PLAN) zu untersuchen, es wird eine grobe Beschreibung der Schritte sein, die die Engine zum Ausführen Ihrer Abfrage verwendet.

Answer 3

Nun, wenn Sie SQL Server verwenden, würde ich sagen, dass Sie die Kosten der Abfrage im Ausführungsplan (insbesondere die Teilbaumkosten) betrachten sollten.

Here ist ein Link, der einige der Dinge durchgeht, die Sie im Ausführungsplan betrachten sollten.

Answer 4

Abhängig von Ihrem RDBMS können Abfrageplan-Tools Ihnen helfen, die Schritte zu analysieren, die das RDBMS beim Abrufen Ihrer Abfrage ausführen wird.

SQL Server Management Studio Express verfügt über einen integrierten Abfrageausführungsplan. Pervasive PSQL hat seinen Abfrageplan-Finder. DB2 verfügt über ähnliche Tools (vergessen, wie sie heißen).

Answer 5

Eine gute Frage. Das Problem ist, dass für eine SQL-Abfrage wie:

SELECT * FROM foo; 

die Komplexität abhängen kann auf das, was „foo“ ist und auf der Datenbank-Implementierung. Für eine Funktion wie:

int f(int n) { 
    if (n == 42) { 
     return 0; 
    } 
    else { 
     return n; 
    } 
} 

gibt es keine solche Abhängigkeit.

Aber ich denke, es sollte möglich sein, einige nützliche Metriken für eine SELECT zu finden, auch wenn sie nicht sehr genau sind, und ich werde interessiert sein zu sehen, welche Antworten das bekommt.

Answer 6

Ich bin nicht sicher, ob das Abrufen der Abfragepläne die Frage beantworten wird: Die Abfragepläne verdecken einen Teil der Komplexität der Berechnung, die an den Daten vor der Rückgabe (oder Verwendung in einem Filter) durchgeführt wurde; Die Abfragepläne erfordern eine aussagekräftige Datenbank, um relevant zu sein. In der Tat sind Komplexität und Ausführungszeit etwas entgegengesetzt; etwas wie "Gut, schnell, billig - wählen Sie zwei".

Letztendlich geht es um die Chancen, einen Fehler zu machen oder den Code, den ich geschrieben habe, nicht zu verstehen?

So etwas wie:

• Anzahl der Tabellen-mal (1
• +1 pro Join-Ausdruck (+1 pro Outer-Joins)
• +1 pro Prädikat nach WHERE oder HAVING
• + 1 pro GROUP BY Ausdruck
• +1 pro UNION oder INTERSECT
• +1 pro Funktionsaufruf
• +1 pro CASE Ausdruck
• )

Answer 7

Nun, ich weiß nicht, jedes Werkzeug, das so etwas tat, aber es scheint mir, dass das, was eine Abfrage machen würde die Anzahl der Joins die Zahl der, wo die Bedingungen die Anzahl der Funktionen die Anzahl der Unterabfragen die Anzahl der Würfe zu differnt Datentypen die Anzahl der Case-Anweisungen die Anzahl der Schleifen oder Cursor: komplizierter durch gemessen werden würdedie Anzahl der Schritte in einer Transaktion

Es stimmt zwar, dass die komplexeren Abfragen möglicherweise die mit den meisten möglichen Fehlern sind, aber ich finde, dass die einfachen sehr wahrscheinlich Defekte enthalten, so wie sie sind Es ist wahrscheinlicher, dass sie von jemandem geschrieben werden, der das Datenmodell nicht versteht und daher scheinbar korrekt funktioniert, aber tatsächlich die falschen Daten zurückgibt. Ich bin mir also nicht sicher, ob eine solche Metrik Ihnen viel erzählen wird.

Answer 8

In Ermangelung von Tools, die dies tun, wäre ein pragmatischer Ansatz, sicherzustellen, dass die Abfragen analysiert werden konsistent formatiert sind und dann die Codezeilen zählen.

Alternativ können Sie die Größe der Abfragen in Byte verwenden, wenn sie in Datei gespeichert werden (wobei darauf zu achten ist, dass alle Abfragen mit derselben Zeichencodierung gespeichert werden).

Nicht brillant, aber ein vernünftiger Proxy für Komplexität in der Abwesenheit von etwas anderem, denke ich.

Answer 9

Bitte zögern Sie nicht mein Skript, um zu versuchen, die einen Überblick über die gespeicherten Prozedur Größe gibt, die Anzahl der Objektabhängigkeiten und die Anzahl der Parameter -

Calculate TSQL Stored Procedure Complexity