Alias Namen in SQL-Abfragen vewenden

[Harry Stahl]

Hi, ich bin gerade dabei, meinem (einfach gehaltenen) Datenbank-Programm ein paar einfache SQL-Abfragen beizubringen (beibringen muss ich, weil ich ein eigenes DB-Format verwende, welches das noch nicht kann).

Ich verwende dazu einen Dialog, der den User bei der Eingabe etwas unterstützen soll (siehe anlg. Screenshot).

Was mir nach Lektüre der SQL-Befehle nicht ganz klar ist: wenn man Alias Namen für Felder verwendet, müssen dann in weiteren SQL-Befehlen (z.B. Order by) dennoch die ursprünglichen Feldnamen benutzt werden (oder dürfen auch die Alias-Namen verwendet werden)?

Ich habe hierzu weiter nichts gefunden, aber ich würde mal davon ausgehen, dass nur die ursprünglichen Feldnamen verwendet werden dürfen, oder?

[Aviator]

Also bei MSSQL müssen, zumindest wenn es um JOINS geht, die Alias Namen verwendet werden. Die originalen Feldnamen sind dann nicht mehr verfügbar. Bei normalen Tabellenfeldern die einen Alias erhalten und in einer WHERE-Clause abgefragt werden sollen, müssen weiterhin die originalen Namen verwendet werden.

Siehe anliegenden Screenshot.

[Ghostwalker]

Also für MySQL und Oracle kann ich bestätigen, das vergebene Alias-Namen für Felder NICHT in
weiteren Anweisungen wie Order By verwendet werden dürfen.


Als Leitfaden würde ich mich generell an den SQL-Standard halten.
https://de.wikipedia.org/wiki/SQL#Sprachstandard

hilft dir hier vielleicht weiter


Gruß

Uwe

[Harry Stahl]

OK, alles klar. Hab es jetzt so gemacht, dass die ursprünglichen Feldnamen verwendet werden müssen und erst wenn das Abfrage-Ergebnis als neue Tabelle in die DB übernommen wird, ändere ich die Namen der Sortierfelder für die neue Tabelle (soweit sie Ursprungsnamen hierfür benutzt wurden), da die ja jetzt die Alias-Namen als neue Feldnamen haben.

[HeZa]

Zitat von Harry Stahl:

Hi, ich bin gerade dabei, meinem (einfach gehaltenen) Datenbank-Programm ein paar einfache SQL-Abfragen beizubringen (beibringen muss ich, weil ich ein eigenes DB-Format verwende, welches das noch nicht kann).

Ich verwende dazu einen Dialog, der den User bei der Eingabe etwas unterstützen soll (siehe anlg. Screenshot).

Hallo Stahli,

ich habe in den letzten 25 Jahren schon viele solcher Dialoge gesehen und finde sie alle unpassend.

Meiner Meinung nach gibt es zwei Gruppen:

1. Die Leute die wissen was ein SELECT ist
   Die fühlen sich gegängelt.
2. Und die, die keine Ahnung haben
   Die Produzieren mit solchen Dialogen oft Ergebnisse die sie nicht verstehen (z.B. weil sie mit den logischen Operatoren nicht klar kommen, die sie bei dir noch nicht einmal Klammern können).

Und wenn du der zweiten Gruppe erklärst, wie das mit dem Dialog funktioniert (und sie es verstanden haben) gehören sie zwei Monate später zu der ersten Gruppe.

Mein Tipp:

• Mach etwas einfaches
  Lass es nicht aussehen wie ein SELECT-Statement
  Lass keine unterschiedliche logische Operation zu (alle Bedingungen UND-Verknüpft)
  Er mögliche es Ergebnisse mit gleicher Struktur zusammen zufügen
• Lass die Eingabe eines SELECT-Statments zu
  Stelle "nur" READ-ONLY Rechte zur Verfügung (plus evtl. Schreibrechte für einen USER-Bereich)
  Stelle eine Hilfe bei der Auswahl von Tabellen und Spalten und möglichen Joins zur Verfügung

Ciao HeZa

[p80286]

Dem ist wenig hinzu zu fügen. Vor allem weil kein Programmierer so viel Phantasie entwickelt wie ein Anwender.
Wenn ich es richtig verstanden habe, liegt unter der Oberfläche eine nichtStandardDatenbank. Diesen Zustand sollte man möglichst schnell ändern (so sehr ich auch meinen Hut vor so etwas ziehe) eine StandardSQLDatenbank auch nur annähernd nachzubauen ist meiner Meinung nach unnötiger Aufwand (so reizvoll es sein mag).

gruß
K-H

[jobo]

Ich schließe mich HeZas Empfehlung an!
Nur ein Hinweis zur Verwendung von Aliasen. Gegenüber den beschriebenen Verfahren kenne ich eine Ausnahme, das ist mySQL (wahrscheinlich entsprechend auch Maria DB). Hier können Aliase auch in where, order by, .. verwendet werden, was eine der wenigen angenehmen Features von mySQL ist (das einzige?).
Technisch hat es wohl etwas mit der Auswertungsreihenfolge/Parsing des Statements zu tun. Vielleicht gilt das nicht mal grundsätzlich für mySQl, sondern nur für spezifische Engines- wovon es ja einige bei mySQL gibt. Aber das ist nur Hören/Sagen.
Das nur als Randinfo, denn es ist m.E. für Deinen Einsatzzweck und den Weg, den HeZa vorschlägt, dann unerheblich.

[Harry Stahl]

Ja, vom Prinzip her alles richtig, allerdings habe ich ja erwähnt, dass es ein einfaches Datenbank-Programm ist und solch ein Dialog für meine Zielgruppe sicher hilfreich ist.

Mein Manko (ich habe es hier schon öfters erwähnt) ist, dass ich mich mit den typischen Delphi-DB's nicht auskenne, schaffe es auch leider einfach nicht die Zeit zu finden, mich da mal richtig einzuarbeiten.

Das mit dem Dialog hat auch den Vorteil, dass ich das Leistungsangebot der unterstützen Befehle immer mal wieder etwas ausbauen kann, wenn nach dem einen oder andere Feature gefragt wird (und der User weiß, welche Befehle unterstützt werden (siehe Bildmontage in der Anlage). Ich war ja schon beeindruckt, das mit SQL alles so machbar ist (hier habe ich mich ein wenig schlau gemacht: https://www.w3schools.com/SQL/default.asp).

Alles das werde ich mit Sicherheit nicht unterstützen, ich denke aber auch, dass der einfache Anwender nur einen sehr kleinen Bruchteil davon benötigen wird.

Hatte auch schon überlegt, ein weiteres Direkt-Eingabefeld einzubauen, aber dafür ist der Leistungsumfang noch zu gering und das alles richtig zu parsten ist sicher auch eine kleine Herausforderung. Jedenfalls meine Betatester sind begeistert um diese Erweiterung, hoffe also, dass das dann auch bei den anderen Usern so ist...

[jobo]

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.