Das SALUT-Vorgehen

Es ist kein Geheimnis dass ich ein großer Standard-SQL Fan bin. Diese Sprache ist nicht nur ungemein mächtig ohne dabei aufgebläht zu sein sondern auch minimalistisch in der Syntax. Zwei Eigenschaften die ich als Kriterium dafür werte dass SQL eine ästhetische Sprache ist – wenn man sie denn richtig nutzt.

Eine Sache allerdings hat mich immer gestört und hat auch oft dazu geführt dass vermeintlich einfache Wege unnötig holprig wurden. Ich nenne es mal das SELECT INTO-Problem oder genauer das Problem der Unflexibilität des erwähnten Statements. Was ich damit genau meine ist, dass dieses Statement gerade in Bezug auf Client-Server Applikationen eine große Performanceeinsparung realisieren kann aber diesen Vorteil bei der Flexibilität wieder verliert. Denn in den meisten Fällen braucht man doch keine aggregierte Teilmenge sondern eine erweiterte Ergebnismenge. Also eher sowas wie
Teilmenge + LastUpdated/ SessionId statt Teilmenge aus zwei Tabellen.

In besten Fall wünsche ich mir da sowas wie SELECT 0 AS [Konstanter Wert], * INTO … Weil es nicht nur praktisch sondern auch schnell wäre. Das gibt es so aber leider nicht und damit ist der kleinste Umweg gefragt. Meine präfererierte Lösung ist bsw für ADO in VBA aber auch in Stored Procedures das „SALUT“-Vorgehen:
• SELECT INTO
• ALTER
• UPDATE Table
Also ein SELECT INTO mit einer (Teil-)Menge von aggregierten Daten in eine Ergebnistabelle, dann eine Tabellenerweiterung mit ALTER und einem zufügen von Spalten für die neu hinzuzufügenden Informationen. Beispielsweise einer SessionId. Danach noch ein Update auf die komplette Tabelle in der diese SessionId gesetzt wird und voila haben wir die Anforderung erfüllt.

Das ganze ist performant und auch mit recht wenig Zeilen Code machbar.