Ein behutsamer Kompromiss aus den Empfehlungen und Deinen Ansätzen und Tests ist vielleicht eine gute Idee. Dabei würde ich darauf achten, nichts zu bauen/anzubieten, was mit
SQL nicht (ohne weiteres) geht, auch auf Bezeichnungen und Zusammenhänge- zumindest wenn
SQL das Ziel ist.
Zu dem Screen:
- „Attribut evtl. Count“
meint sehr wahrscheinlich eine Aggregatfunktion wie Count, Sum, .. Diese stehen in direktem logischen Zusammenhang mit „Group By“, der muss stimmen.
Solche Aggregatfunktionen sind streng zu unterscheiden von „normalen“, wie z.B. Teilstring(), Kleinbuchstaben(), QuadratWurzelAus().. bzw. den
SQL Pendants. Diese würden -wenn man sie möchte/braucht- mit in die Feldnamenspalte gehören und haben natürlich nichts mit Gruppierung zu tun.
Richtige Gruppierung muss der Nutzer angeben, falsche Gruppierung muss das Programm als Fehler ausgeben. (Abfrage nicht ausführbar) An einer möglichen Automatik scheitert
mySQL seit Jahren, liefert falsche Ergebnisse und macht Entwickler wahnsinning. Andere Systeme geben nur Fehlermeldungen aus.
-Ergebnis
Hier wäre ich vorsichtig, Abfragedaten mit Bestandsdaten wahllos zu vermischen. Es bietet sich an, nicht nur Ergebnisse zu speichern, sondern auch die ursprüngliche Abfrage, vielleicht sogar eine (überwachte) Historie oder Verkettung. Ebenso das Löschen von Ergebnissen, wenn sie in Deiner Datenbank abgelegt werden.
So holt man noch etwas mehr raus und vermeidet „adhoc“ Workflows, die durcheinander geraten und nicht mehr funktionieren.
Was
SQL selbst angeht, kannst Du vielleicht mal schauen, ob es Parser zur freien Verwendung gibt.