Hello,

zunächst mal kriegst du ein "fachlich hilfreich" von mir, soviel vorweg! In deinem Posting steckt mit Sicherheit eine Menge Wahrheit drin.

Ich bin in den vergangenen zwei Jahren nur sehr nachrangig mit Datenbanken beschäftigt gewesen, aber arbeitsbedingt befasse ich mich gerade mit äußerst unschönen Daten- und Tabellenkonstellationen und kann aus dieser Perspektive nur ein paar Erfahrungen wiedergeben (die übrigens auch die von dir genannten Kommentare in SQL-Statements mit betreffen). Ich werde auch vorweg sagen, dass gerade Hobby-Entwickler mit Problemen dieser Dimension selten bis nie konfrontiert sein werden.

Beispiel zu den Kommentaren:
ein aktuelles Projekt läuft bei einem Kunden, dessen datenbankgestützte IT-Systeme mehrere Jahrzehnte alt sind. Alleine hierin fundieren politische Strukturen, die zu Entscheidungen führen, die auf den ersten Blick wenig sinnvoll erscheinen, so z.B. ablehnende Haltungen gegenüber Stored Procedures für unsere Zwecke. Dies zwingt uns eine Vielzahl von SQL-Statements, möglichst wartbar, außerhalb der Datenbank zu lagern. Die Statements haben eine derartige Komplexität erreicht, dass man praktisch jede Zeile kommentieren müsste, u.a. auch der Nachverfolgbarkeit von Defectfixes wegen. Es ist für uns deshalb durchaus ein realistischer Ansatz kommentierte Statements aus Resource-Dateien einzulesen und abzuschicken, wobei ich zugeben muss, dass die Kommentare selten direkter Bestandteil des SQL-Codes sind.

SELECT * hingegen lehne ich in einer Produktionsumgebung vehement ab. Unser derzeit entwickeltes System (bzw. diese Version) wird, wenn es gut läuft, lediglich 3-4, wenn es schlecht läuft deutlich länger laufen. Das Produkt, auf dem es aufsetzt, wird zwischenzeitlich auf eine neue Version migriert, deren Datenstrukturen sich teilweise deutlich von den aktuellen unterscheiden, insbesondere was Spalten, Defaultwerte etc. angeht. Wenn wir uns nun darauf verlassen, JOINs und anschließende Gruppierungen auf einem SELECT * aufzubauen, können wir mit 100% Wahrscheinlichkeit davon ausgehen, dass wir Nachbesserungen vornehmen müssen. Können wir hingegen die selektierten Spalten benennen, so ist die Wahrscheinlichkeit deutlich geringer. Was noch hinzukommt: das zugrundeliegende Datenmodell ist normalisiert, relevante Daten zu ermitteln, noch dazu in Archivbeständen, erfordert in den meisten Fällen eine ganze Reihe von JOINs. Ich mag gar nicht darüber nachdenken, wie man in derartigen Abfragen ohne angemessene Selects den Überblick über die Ergebnisspalten behalten möchte.

Und bezüglich des GROUP BY: ja, natürlich kann man den Gruppierungsvorgang erleichtern. Aber hiergegen habe ich zwei Einwände:

1. Der SQL-Standard sieht IMHO die MySQL-Variante NICHT vor. Wieso pochen wir bei HTML so darauf den Standards des W3C zu folgen, nur damit verlässliche Verarbeitung möglich wird, und sind bei SQL so nachlässig? Ein Standard ist ein Standard, warum darf man hier plötzlich die Standardsyntax benutzen, aber sich abweichend verhalten?
2. Ein Grund, warum Reflection/Eval/wie auch immer man es nennen mag verteufelt wird ist doch, dass man die Ausführung des Codes nicht vorhersagen kann. Eine syntaktische Validierung, die Analyse von Abhängigkeiten, der Programmfluss ist nicht durch Betrachtung des Quelltextes erkennbar. Genau hierauf läuft es doch bei der nicht-strikten GROUP BY Variante auch hinaus. Das Datenbanksystem akzeptiert einen Befehl, von dem es sagen kann "sieht vermutlich gut aus, ich kann dir aber nicht versprechen, dass die Auswertung dein Ergebnis ergibt - das hängt von der Datenkonstellation ab". Bei einem einfachen JOIN mag der Programmierer überblicken, ob die Auswahl der nicht-gruppierten Spalten eindeutig ist. Was ist, wenn der JOIN komplexer wird? Das DBMS wird keine Warnung rausgeben und sagen "oops, ich glaub da könnte was daneben gehen". Ich ändere ein Statement, ändere ein paar Daten und die Semantik meiner Abfrage ändert sich. Ich persönlich, und ja, ganz offensichtlich darf man hier geteilter Meinung sein, finde das gefährlich.

Wobei ich nicht leugnen werde, dass mir die eingangs erwähnten komplexen Statements im Projekt um einiges leichter von der Hand gingen, wenn ich etwas mutwilliger gruppieren dürfte :-)

Geruhsame Nacht, mich erwarten morgen weitere Multi-Bildschirmseiten-Queries!

MfG
Rouven