Zugegebenermassen ein etwas reisserischer Titel, nicht wahr? Aber in Zeiten, wo man stets mit Superlativen zugeschmissen wird, durchaus angebracht, um überhaupt etwas Aufmerksamkeit zu erregen. :-)

Über die Jahre hinweg haben sich Online-Communities als fester Bestandteil des Wissens-Transfer von erfahrene(re)n Entwicklern an weniger Erfahrene etabliert. Leider hat sich ein Mindestmass an Netiquette in diesem Zusammenhang (immer noch) nicht gleichermassen etabliert. Auch nach ca. 12 Jahren, in denen ich nun mehr oder weniger regelmässig in diversen SQL Server Communities unterwegs bin, vermisse ich oftmals eben diesen gewissen Mindeststandard. Seit Jahren existiert dieser Beitrag bereits in meinem Kopf, hat sich aber erst jetzt seinen Weg herausbahnen können.

Derjenige, der sich mit einem Abfrage-, oder besser gesagt, einem T-SQL orientierten Problem, an eine Community wendet, sollte sich über einige Punkte im Klaren sein:

1. Die "Regulars" der allermeisten Communities sind KEINE von dieser Community bezahlten Fachkräfte: Sie helfen aus den unterschiedlichsten Motiven unentgeltlich in ihrer Freizeit. Daraus kann man ableiten, dass der Antwortsuchende weder ein "Recht" noch einen "Anspruch" auf eine Antwort hat. Erst recht nicht innerhalb einer bestimmten Zeit. Natürlich ist jedes Problem dringend und bedarf einer schnellen Lösung, aber zunächst einmal löse ich die Probleme an meinem eigenen Arbeitsplatz, bevor ich mal schaue, "was es so neues in der Community gibt". Wer dafür kein Verständnis hat, sollte vielleicht auf die Dienste eines Freelancers und/oder Consultants zurückgreifen. Also, bitte Wörter wie "DRINGEND" oder "HILFE" (vielleicht sogar noch in Grossbuchstaben) weglassen!
2. Ein Mindestmass an Eigeninitiative und eigenem Research darf vorausgesetzt werden: Wenn man mal ehrlich ist, ist T-SQL keine Sprache, die sich stets neu erfindet und mit der stets neuartige Probleme gelöst werden müssen. Viele der Probleme existieren in der einen oder anderen Form wahrscheinlich seit Jahrzehnten. Dies wiederum erhöht jedoch die Wahrscheinlichkeit enorm, dass sich der eine oder andere mal die Zeit genommen hat, solche Probleme für die Nachwelt zu dokumentieren, zu lösen und einer breiteren Masse zugänglich zu machen. An diesem Punkt zahlt es sich aus, dass das Internet nie vergisst. Also, ruhig einmal die eigene Lieblingssuchmaschine für das Internet anwerfen, bevor man diesen Link als Antwort erhält.
3. Ein aussagekräftiges Betreff: "Problem mit einer Abfrage" als Betreff ist weniger als nichtssagend. Natürlich hat derjenige, der Hilfe sucht, ein Problem mit einer Abfrage. Ansonsten bräuchte er ja keine Hilfe suchen. Also, bitte, etwas mehr Kreativität!
4. In der Kürze liegt die Würze: Ja! Der Mensch ist ein kommunikatives Wesen (meistens), aber bezogen auf ein technisches Problem ist weniger oftmals mehr. Wenn man einen Roman braucht, um ein Problem zu beschreiben, hat man wahrscheinlich das Problem selber nicht richtig analysiert und/oder verstanden. Zudem sollte man sich in der Situation des Lesenden versetzen. Man verliert schnell die Lust, sich mit dem Problem einen anderen auseinanderzusetzen, wenn man sich erst durch viele Zeilen von Text lesen muss, die vielleicht etwas mit dem Problem zu tun haben, nur um am Ende vielleicht festzustellen, dass man nicht wirklich schlauer ist. Es ist Übungssache, sich klar und präzise auszudrücken, aber es ist die Mühe wert.
5. Die Rechtschreibung: Niemand ist fehlerfrei! Selbst wenn man die Zeit und die Ruhe hat, um einen Text zu schreiben, können Fehler stets passieren. Umso mehr gilt dies, wenn man in einer Online Community postet. Man hat wenig Zeit, ist unter Stress, unkonzentriert, es gibt keine Rechtschreibprüfung. usw. Ja, ist verständlich und passiert jedem. Aber...
   Auch hier wieder der Hinweis darauf, sich einmal zu überlegen, wie das auf denjenigen wirkt, der potentiell das Problem lösen soll. Bei mir hinterlässt es ein zwiespältiges Gefühl, wenn ich ein Posting lese, welches vor Schreibfehlern nur so strotzt. Da kommt wahrscheinlich der Vater in mir zu sehr durch und oftmals juckt es mich in den Fingern, eine Korrektur zu posten (wohlwissend dass ich wahrscheinlich nichts ausser einem Flame War erreiche). Also, vielleicht etwas Zeit nehmen, das Posting als Ganzes zu überfliegen, bevor man es absendet.
6. Emoticons: Emoticons sind wichtig und aus der elektronischen Kommunikation nicht mehr wegzudenken. Zitat aus Wikipedia:

   Emoticons sind für die Teilnehmer an der Internetkommunikation eine wichtige Methode ihre Gefühlslage deutlich zu machen. Die Internetkommunikation läuft im Gegensatz zur direkten Kommunikation (englisch: Face-to-Face Communication) ohne sichtbares Gegenüber, dessen Gesten, Mimik und Stimmausdruck gedeutet werden könnte um neben dem Wortinhalt Aufschluss über die Einstellung zum Gegenüber, Aussagen über die Wahrhaftigkeit und Bedeutung der Aussage sowie den emotionalen Zustand zu erhalten. Auch die soziale Rolle des Sprechers (Geschlecht, ungefähres Alter, Hautfarbe, Kleidung, Frisur etc.) geben Anhaltspunkte über die Bedeutung des Sprachinhalts. So ist zum Beispiel eine ironische Aussage in der Schriftform oft allein am Wortinhalt nicht zu verstehen. Um den Bedeutungskontext der Aussagen zu verdeutlichen, helfen Emoticons. Anders als bei anderen Formen der textbasierten Kommunikation, wie dem Brief, treffen sich im Internet oft Unbekannte. Dies macht es noch schwieriger, den Bedeutungskontext zu entschlüsseln. Die Emoticons sollen hierbei helfen, die Zahl der Missverständnisse zu reduzieren.

7. Respekt und Höflichkeit: Selbstverständlichkeiten sollte man meinen. In den allermeisten Fällen trifft dies auch zu. Im Gegensatz zu anderen Online Communities zu anderen Themen, fällt mir immer wieder die SQL Server Community durch ein hohes Mass an Professionalität, Respekt und Höflichkeit auf. Ich habe kaum verbale Entgleisungen beobachtet und auch viele andere, eher unangenehme Begleiterscheinungen wie Trolle, scheinen kein wirkliches Problem zu sein. Trotzdem möchte ich diesen Punkt nicht unerwähnt lassen.
8. Feedback: Dieser Punkt könnte auch unter dem vorherigen subsumiert werden. Ich habe ihm aber einen eigenen Punkt gewidmet, weil er so mehr Aufmerksamkeit erhalten dürfte. Feedback ist wichtig! Jeder, der Fragen in einer Community beantwortet, erhält gerne Feedback, ob sein Lösungsvorschlag richtig und gut ist. Ein kleines Danke von Seiten des Fragestellenden, zeigt nicht nur, dass dieses Problem gelöst ist, sondern hat auch einen enormen, nicht zu unterschätzenden Effekt auf die Motivation des Antworters, sich auch weiterhin aktiv an der Community zu beteiligen. Dies gilt umso mehr für Leute, die sehr viel Aufwand in ihre Antworten stecken und deren Antworten sehr professionell, ausführlich und detailiert sind.
   Ferner hilft Feedback Leuten, die auf der Suche nach einer Lösung zu ihrem eigenen Problem durchs Internet surfen und auf diesen Thread stossen. Diese Leute können vielleicht schon aufgrund dieses Feedbacks entscheiden, ob ihre Suche nun ein Ende hat, oder sie leider doch noch weitermachen müssen.

Eine gute Problembeschreibung verfassen

Nun nachdem ich mich darüber ausgelassen habe, was ich NICHT in einer Community Frage sehen möchte, wird es Zeit, zu beschreiben, wie eine gute Problembeschreibung mit relativ geringem Aufwand erreicht werden kann. Das Ganze lässt sich auf 5 Kernpunkte reduzieren:

1. Angabe der verwendeten Version von SQL Server
2. DDL
3. Beispieldaten
4. Erwartete Ergebnismenge
5. Ausführungsplan und Co.

Angabe der verwendeten Version von SQL Server

Eine der wichtigsten Information, die auf keinen Fall in einer Frage fehlen darf, ist die, mit welcher Version von SQL Server die Fragenstellende arbeitet. Diese Angabe hat eine unmittelbare Auswirkung auf die potentielle Lösung des Problems. Was nutzt die "beste" Lösung, wenn sich im Nachhinein herausstellt, dass die so nicht verwendbar ist, weil sie von der SQL Server Version des Fragenden nicht (mehr) unterstützt wird? Üblicherweise ist die Gegenfrage nach der SQL Server Version eine der ersten, die gestellt wird, falls diese Angabe fehlt. Liefert man diese jedoch gleich in seiner Frage mit, spart man allen Beteiligten Zeit und kommt so wahrscheinlich schneller zu einer guten Lösung.
Wie jedoch ermittelt man die Version von SQL Server, mit der man arbeitet? Dieser Beitrag zeigt diverse Möglichkeiten dazu auf.

DDL

DDL ist die Abkürzung für Data Definition Language und wird üblicherweise auch als Tabellenstruktur bezeichnet. Eines der zahlreichen coolen Features im SQL Server Management Studio, ist die Fähigkeit, sich ein fertiges Skript einer Tabelle erstellen zu lassen. Dazu geht man in den Object Explorer:

Anschliessend wählt man die gewünschte Tabelle aus dem entsprechenden Unterpunkt aus:

Öffnet mit der rechten Maustaste das Kontextmenü und klickt sich gemäss der nachfolgenden Abbildung durch:

Als Ergebnis präsentiert sich ein schickes Skript

Es sollte sich übrigens von selbst verstehen, dass man diesen Vorgang für ALLE an dem Problem beteiligten Tabellen wiederholt.

In diesem Zusammenhang erwähnenswert sind noch die diversen Optionen, die der Anwender hat, um die Skripterstellung ganz den eigenen Wünschen anpassen zu können. Leider hat Microsoft die an einem Ort versteckt, wo man sie nicht unbedingt als erstes vermuten würde:

Dies bringt den nachfolgenden Dialog zum Vorschein. Unter SQL Server Object Explorer -> Scripting findet man dann eine ganze Reihe an nützlichen Einstellungen, die man ganz nach Belieben adjustieren kann.

Beispieldaten

Etwas schwieriger ist die Bereitstellung von Beispieldaten. Bereits vor Jahren hat sich ein geschätzter Kollege diesem Problem angenommen. Unter http://vyaskn.tripod.com/code/generate_inserts.txt findet man nach wie vor den Source Code einer Prozedur, die man zum Generieren von INSERT Statements verwenden kann.

Quasi als De-Luxe Version davon kann man auch SSMS Tools Pack verwenden. Dies gibt einem die Möglichkeit aus dem Kontextmenü heraus, INSERT Statements zu generieren

Als Ergebnis erhält man ein neues Query Window, in dem die INSERT Statements angezeigt werden.

Leider hat der Entwickler des SSMS Tools Pack Bundles den Lizensierungs-Modus beginnend mit SSMS 2012 geändert. Die Tools sind nun nicht länger kostenlos einsetzbar. Die Kosten halten sich aber in einem überschaubaren Rahmen und stellen keinen ernsthaften Show-Stopper dar.

Alternativ kann auch die Skripterstellung im Management-Studio verwendet werden. Man findet diese im Kontextmenü der Datenbank unter dem Namen "Tasks->Skripts generieren".

Unter den Skripterstellungsoptionen (Button Erweitert) kann man wählen, ob man zu einer Tabelle nur die "Daten", nur das "Schema", oder "Schema und Daten" skripten möchte.

An dieser Stelle vielleicht noch ein Wort der Warnung: Man sollte niemals unbedacht, die INSERT Statements generieren und das Ergebnis verwenden! Zum einen sollte man überprüfen, ob es sich eventuell um sensitive Daten handelt, die man lieber nicht in einem öffentlichen Forum preisgibt. Zum anderen braucht es keinen Tausende von Datensätzen, um ein Problem reproduzierbar zu machen. In aller Regel reicht hier eine Handvoll an Datensätzen vollkommen aus.

Erwartete Ergebnismenge

Bleibt noch die "Erwartete Ergebnismenge". Also, das, was von SQL Server zurückgegeben werden soll, wenn die Beispieldaten verarbeitet worden sind. Eine tabellarische Darstellung des gewünschten Ergebnisses ist hier völlig ausreichend, meiner Meinung nach.

Ausführungsplan und Co.

Bereits mit recht geringen Mitteln, kann man eine Menge an nützlichen Informationen sammeln lassen und damit die Community bei der Beantwortung von Fragen zur Performance unterstützen.

-- I/O Informationeen
SET STATISTICS IO ON;

-- CPU-Informationen
SET STATISTICS TIME ON;

-- Ausführungsplan
SET STATISTICS PROFILE ON;

-- Abfrage
SELECT ...

Schlussbemerkung

Sind alle diese "Voraussetzungen" erfüllt, stehen üblicherweise die Chancen nicht schlecht, dass sich jemand für das Problem interessiert und eine Lösung vorschlägt. Ist dies der Fall, sollte man als Hilfesuchender jetzt auf keinen Fall den gesunden Menschenverstand über Bord werfen. Also, auf jeden Fall erst einmal die vorgeschlagene Lösung auf einem Test-System analysieren und "ausprobieren". Was in einer Testumgebung mit den gelieferten Beispieldaten eine gute Performance zeigt, kann sich in der Zielumgebung mit den Produktionsdaten schnell zu einer Performance-Killer entwickeln und die Sache eventuell noch verschlimmern. Also, auch wenn die Zeit drängt, weil der Chef und/oder der Kunde einem im Nacken sitzt: NIE Source-Code aus einer Online Community ungetestet verwenden. Egal, von welcher Quelle dieser Code stammt!

Zu guter Letzt noch etwas, was ich persönlich immer bedauerlich finde. Ich bin mir bewusst, dass es unzählige Arten und Weisen gibt, wie Source Code formatiert wird und jeder Entwickler hat da seine ganz eigenen Vorstellungen von. Alle diese Vorstellungen sind richtig und berechtigt und gleichwertig. Allerding macht es demjenigen, der helfen möchte, die Sache nicht wirklich einfacher, wenn man erst einmal Zeit damit verbringen muss, den Code in ein übersichtliches Format zu bringen, um anschliessend zu versuchen, das Problem des Fragestellers zu begreifen und zu lösen. Diesem Problem kann man mit Hilfe eines der zahlreichen freien Online Formatierern für SQL Code erfolgreich begegnen. Stellvertretend für diese kleinen Tools sei hier http://www.sql-format.com/ erwähnt.