Messung der Komplexität von SQL-Anweisungen

Question

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

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

[Bearbeiten/Hinweis] Es ist zwar nützlich, den Ausführungsplan zu erhalten, aber das ist nicht unbedingt das, was ich in diesem Fall zu identifizieren versuche. Ich suche nicht danach, wie schwierig es für den Server ist, die Abfrage auszuführen, sondern ich suche nach einer Metrik, die angibt, wie schwierig es für den Entwickler war, die Abfrage zu schreiben und wie wahrscheinlich es ist, dass sie einen Fehler enthält.

[Bearbeiten/Anmerkung 2] Zugegeben, es gibt Zeiten, in denen die Messung von Komplexität nicht sinnvoll ist, aber es gibt auch Zeiten, in denen sie sinnvoll ist. Für eine weitere Diskussion zu diesem Thema, siehe diese Frage .

Answer 1

Gängige Maßstäbe für Softwarekomplexität sind Zyklomatische Komplexität (ein Maß dafür, wie kompliziert der Kontrollfluss ist) und Halstead-Komplexität (ein Maß für die Komplexität der Arithmetik).

Der "Kontrollfluss" in einer SQL-Abfrage ist am besten mit den "und"- und "oder"-Operatoren in der Abfrage verbunden.

Die "rechnerische Komplexitä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 einen "Kontrollfluss" oder eine "Berechnung" handelt, können Sie ganz einfach zyklomatische oder Halstead-Maße berechnen.

Was der SQL-Optimierer mit Abfragen macht I denken ist absolut irrelevant. Der Zweck von Komplexitätsmaßen ist es, zu charakterisieren, wie schwer es für eine Person ist, die Anfrage zu verstehen, und nicht, wie effizient sie ausgewertet werden kann.

Ebenso sollte die DDL oder die Frage, ob Views involviert sind oder nicht, nicht in solche Komplexitätsmessungen einbezogen werden. Die Annahme hinter diesen Metriken ist, dass die Komplexität der Maschinerie innerhalb einer verwendeten Abstraktion nicht interessant ist, wenn man sie einfach aufruft, weil diese Abstraktion vermutlich etwas tut, was der Programmierer gut versteht. Das ist der Grund, warum Halstead und Cyclomatic-Maße keine aufgerufenen Unterprogramme in ihre Zählung einbeziehen, und ich denke, man kann gut argumentieren, dass Views und DDL-Informationen solche "aufgerufenen" Abstraktionen sind.

Wie richtig oder falsch diese Komplexitätszahlen sind, spielt keine große Rolle, solange sie eine gewisse Wahrheit über Komplexität widerspiegeln und man sie miteinander vergleichen kann. Auf diese Weise können Sie auswählen, welche SQL-Fragmente am komplexesten sind, sie also sortieren und Ihre Tests auf die kompliziertesten konzentrieren.

Answer 2

Ich bin mir nicht sicher, ob die Abfrage der Abfragepläne die Frage beantworten wird: Die Abfragepläne verbergen einen Teil der Komplexität der Berechnungen, die mit den Daten durchgeführt werden, bevor sie zurückgegeben (oder in einem Filter verwendet) werden; die Abfragepläne erfordern eine signifikante Datenbank, um relevant zu sein. In der Tat sind Komplexität und Ausführungsdauer in gewisser Weise gegensätzlich; so etwas wie "Gut, schnell, billig - such dir zwei aus".

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

Etwa so:

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

Answer 3

Sie können gerne mein Skript ausprobieren, das einen Überblick über die Größe der gespeicherten Prozedur, die Anzahl der Objektabhängigkeiten und die Anzahl der Parameter gibt -

TSQL Stored Procedure Komplexität berechnen

Answer 4

Nun, ich kenne kein Tool, das so etwas tut, aber es scheint mir, dass das, was eine Abfrage komplizierter machen würde, daran gemessen würde: die Anzahl der Verknüpfungen die Anzahl der Where-Bedingungen die Anzahl der Funktionen die Anzahl der Unterabfragen die Anzahl der Casts auf verschiedene Datentypen die Anzahl der Case-Anweisungen die Anzahl der Schleifen oder Cursor die Anzahl der Schritte in einer Transaktion

Es stimmt zwar, dass die komplexeren Abfragen die mit den meisten möglichen Fehlern zu sein scheinen, aber ich finde, dass die einfachen Abfragen sehr wahrscheinlich Fehler enthalten, da sie mit größerer Wahrscheinlichkeit von jemandem geschrieben werden, der das Datenmodell nicht versteht, so dass sie scheinbar korrekt funktionieren, aber in Wirklichkeit die falschen Daten zurückgeben. Ich bin mir also nicht sicher, ob eine solche Metrik viel aussagen würde.

Answer 5

In Ermangelung von Werkzeugen, die dies ermöglichen, wäre ein pragmatischer Ansatz, sicherzustellen, dass die analysierten Abfragen einheitlich formatiert sind, und dann die Codezeilen zu zählen.

Alternativ können Sie auch die Größe der Abfragen in Bytes verwenden, wenn sie in einer Datei gespeichert werden (achten Sie darauf, dass alle Abfragen mit der gleichen Zeichenkodierung gespeichert werden).

Nicht brillant, aber ein angemessener Ersatz für Komplexität in Ermangelung von etwas anderem, denke ich.