Tag: "t-sql"
JOIN Stolperfallen Teil 1
Gelegentlich fragt man sich, ob man wirklich so oft auf die Tastatur hämmern muß, oder ob man sich nicht das eine oder andere Zeichen oder Wort sparen kann. Klingt bekannt? Nun, zumindest mir geht es so. Generell ist das auch so in Ordnung, nur manchmal kann man dabei auch auf die Nase fallen. Wenn dann noch eine merkwürdige Syntaxauslegung ins Spiel kommt, wird es richtig interessant. Beispiel:
SELECT r.royalty , t.title , t.type , t.price FROM roysched r INNER JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Die Ergebnismenge wird hier nicht wiedergegeben. Das obige Beispiel läßt sich folgendermaßen "vereinfachen":
SELECT r.royalty , t.title , t.type , t.price FROM roysched r JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Das INNER Schlüsselwort kann man weglassen, da der INNER JOIN der Standard JOIN Type des SQL Servers ist. So weit, so gut!
Schaut man sich den Ausführungsplan an, sieht man, daß SQL Server NESTED LOOPS verwendet. Nun sind NESTED LOOPS gerade bei umfangreichen Abfragen nicht gerade optimal und darum kommt man vielleicht auf die Idee, den Server einen kleinen Hinweis mit auf den Weg zu geben, wie er den JOIN verarbeiten soll. Also schreibt man:
SELECT r.royalty , t.title , t.type , t.price FROM roysched r MERGE JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Was passiert?
Server: Nachr.-Nr. 170, Schweregrad 15, Status 1, Zeile 8 Zeile 8: Falsche Syntax in der Nähe von 'MERGE'.
Was soll das denn jetzt? Sieht doch syntaktisch einwandfrei aus. Ein Blick in BOL bestätigt dies. Warum also wird das Statement nicht ausgeführt???
Der Grund liegt darin, daß SQL Server bei der Verwendung des MERGE Hinweises (oder jedes anderen JOIN Hints) zwingend auf das INNER Schlüsselwort besteht. Ohne dem geht hier gar nichts. SQL Server ist hier nicht in der Lage, den INNER JOIN als Standard JOIN Typ anzuwenden. Also doch wieder ein paar Mal mehr auf die Tastatur hämmern
SELECT r.royalty , t.title , t.type , t.price FROM roysched r INNER MERGE JOIN titles t ON r.title_id = t.title_id ORDER BY r.royalty
Ah, unsere 86 Zeilen kommen zurück und der Ausführungsplan zeigt den MERGE JOIN an. "By design", also nicht wundern oder nachfragen.
Nichtnumerische Zeichen aus einem String entfernen
Das Problem hat wahrscheinlich jeder schon einmal gehabt. Man stellt Importanforderungen auf, und die Anwender kümmern sich nicht darum und liefern anstelle von sauber getrennten Strings und Zahlen einen bunten Mischmasch aus beidem.
n Datensätze pro Gruppierung anzeigen
Zugegeben ist das Subjekt nicht sehr treffend, aber im Moment fällt mir kein Besseres ein.
Gestern stellte jemand auf SQL Server Central.com die Frage, wie man zu jedem Namen mehr als ein Datum anzeigen kann. Genauer gesagt, die beiden aktuellsten Daten. Diese Frage kann man leicht auf die Northwind Beispieldatenbank übertragen: Zeige mir zu jedem Kunden die beiden letzten Bestelldaten ein.
Unterschiede zwischen ISNULL und COALESCE
Es gibt keine Unterschiede zwischen ISNULL und COALESCE. Diese Meinung kann man recht häufig in Online Communities lesen. Der einzige Unterschied zwischen beiden ist, daß ISNULL SQL Server spezifisch ist, während COALESCE ANSI-SQL Standard ist. Auch dies kann man recht häufig lesen. Beide beschäftigen sich mit der Umwandlung von NULL und damit fehlenden Informationen. Wozu also einen eigenen Beitrag?
Spaltenwerte als kommaseparierte Liste zurückgeben
Wie so oft mag man sich fragen, ob dies eher die Aufgabe des Clients als die des Server ist, aber da man häufig derartige Fragestellungen beobachten kann, hier an dieser Stelle vielleicht ein paar Lösungsansätze zu folgendem Problem:
Muss man T-SQL Variablen explizit aufräumen
Nun, so etwas wie Set < variable > = Nothing oder ein Äquivalent in einer anderen Programmiersprache gibt es in T-SQL nicht. T-SQL Variablen sind nur lokal im Batch oder in einer Gespeicherten Prozedur gültig, in der sie definiert wurden. Wird der Batch oder die Prozedur beendet, existiert auch die Variable nicht mehr. Beispiel (Query Analyzer):
IP-Adressen sortieren
Nun, grundsätzlich würde ich wahrscheinlich eher zu einem anderen Datentyp als VARCHAR tendieren, um IP Adressen zu speichern, aber dennoch fand ich diese "Koproduktion" der beiden SQL Server MVP's Steve Kass und Itzik Ben-Gan in der englischen Newsgroup sehr interessant. Folgender Lösungsansatz kam von Steve Kass
Binärzahl in Dezimalzahl umwandeln
Normalerweise würde man solche Fragestellungen. welcher Dezimalzahl nun 1011001 entspricht, damit beantworten, in dem man auf den Client verweist. Was aber, wenn man einfach wissen will, wie so etwas in T-SQL aussehen könnte? Ob man es dann später einsetzt, ist ja eine andere Sache:
