SQL Statement speichern

[himitsu]

Zitat:

Zitat von Jasocul (Beitrag 1525604)

weil im DFM mittendrin umgebrochen wird.

und das seit knapp 30 Jahren auch noch extrem kurz. (bei länger wäre es unwahrscheinlicher, dass die geringere Masse an Umbrüchen stört, falls es überhaupt noch welche gibt, die man nicht selbst gemacht hat)

Delphi-Quellcode:

const LineLength = 64;

und

Delphi-Quellcode:

BytesPerLine = 32;

:wall:

[IBExpert]

Ich für meinen teil speicher die SQLs direkt in der Datenbank ab, weil ich auf dem Weg extrem gut customizen kann.

Wenn ein Kunden in der Auswahlmaske andere Felder sehen will, die auch noch extra aus anderen Tabellen per
join geholt werden müssen, die beim anderen Kunden evtl gar nicht existieren, kann das grid da für die auswahl
einfach den dafür passend benannten sql aus der sql tabelle holen und dann eben anzeigen was da gewünscht ist.
Bei Verfügbarkeit (wie in firebird) könnten das dann auch gleich views oder SPs sein. Und aus der Exe heraus
könnte der Default sql selbst in die Datenbank geschrieben werden, wenn da noch keine angepasste Version
zu finden ist.

Bei bedarf können dann die gleichen Grids sogar userbezogen andere sqls aus der datenbank holen so das ein
Mitarbeiter in der Produktion bei der Auftragsübersicht ganz andere Daten sieht als einer in der Buchhaltung.

[Delphi.Narium]

Noch ein Vorteil dieses Vorgehens:

Wird die Datenbank gewechselt oder müssen unterschiedliche Datenbanksysteme unterstützt werden, so kann, durch "einfachen" Austausch der SQLs in der Datenbank, die Software an die unterschiedlichen Besonderheiten der SQL-Syntax der diversen Datenbanksysteme angepasst werden, wie da z. B. wären: Top 100 <-> First 100 <-> Limit 100 <-> RowNum <= 100, ...

Das Programm selbst muss dafür nicht modifiziert bzw. in jeweils angepassten Versionen vorgehalten und gepflegt werden.

[Uwe Raabe]

Zitat:

Zitat von Delphi.Narium (Beitrag 1525622)

Wird die Datenbank gewechselt oder müssen unterschiedliche Datenbanksysteme unterstützt werden, so kann, durch "einfachen" Austausch der SQLs in der Datenbank, die Software an die unterschiedlichen Besonderheiten der SQL-Syntax der diversen Datenbanksysteme angepasst werden

Zumindest FireDAC bietet in diesem Bereich einige Möglichkeiten dies in einem einzigen SQL-Text unterzubringen. Das ist gerade was den Pflegeaufwand betrifft auch ein Vorteil, da das SQL nur einmal vorhanden ist und somit auch nur das angepasst oder erweitert werden muss. Bei einer externen Lösung kann das schon etwas aufwändiger werden.

Man muss halt immer das Gesamtsystem betrachten um die am besten geeignete Lösung zu finden.

[jobo]

Wenn man SQL eh schon in der DB speichert, dann vielleicht direkt Views, die per se in der DB liegen.
Felder (fields) pro Maske mit Sichtbarkeit, Editierbarkeit usw., natürlich auch aus der DB, mglw. lokal gecached.
Und natürlich die From Clause (also Viewnamen), ggF. Filtervorgaben.
Das vereinfacht Änderungen, zentral, oftmals ohne Anwendungsänderung und -Deployment.
Es erhöht die Flexibilität und Manipulation geht nur über Datenbankzugriff.

Wirklich nett ist das mit RDBMS, deren Views ohne weiteres Editierbar sind (Die View Logik muss das natürlich erlauben, tut sie aber meist und wenn nicht, ist es vermutlich ein Report Datensatz, der eh nicht editierbar ist).

Apropos, Reports, Exports usw., die auf Views basieren, lassen sich natürlich ebenfalls bequem und zentral anpassen, korrigieren, erweitern.

[hoika]

Hallo,
ich als Entwickler der App bin der Chef über sämtliche SQL-Queries,

nix wird zwischengespeichert!

SQL-Fehler
App V2 wird geladen, nutzt "optimierte" Query.

Punkt!

[Redeemer]

Zitat:

Zitat von Jasocul (Beitrag 1525604)

Zitat:

Zitat von freimatz (Beitrag 1525594)

Unsere App benutzt zwar intensiv DBs, aber ich habe direkt recht selten mit SQL zu tun. Interessehalber die Frage: wieso sollte man SQL Statements in der Registry oder in einer Ini speichern? Ich kenne das halt so, dass diese in den DB-Komponenten direkt gespeichert ist oder der SQL-Code mittels Delphi-Code zuusammengebaut wird.

Bei kleinen Anwendungen oder wenigen SQL-Statements innerhalb der Anwendung geht das noch. Aber irgendwann fängt man an, für jede "abweichende" Abfrage ein neues TQuery ins DataModule zu packen. Ich habe schon DataModule gesehen, auf denen soviele Queries drauf waren, dass niemand mehr wusste, wo was drin steht.

Steinigt mich, aber ich in meinen Projekten gibt es nicht eine TQuery zur Entwurfszeit. Allerdings gibt es auch keine DB-Komponenten.

[Uwe Raabe]

Zitat:

Zitat von Redeemer (Beitrag 1525648)

Steinigt mich, aber ich in meinen Projekten gibt es nicht eine TQuery zur Entwurfszeit. Allerdings gibt es auch keine DB-Komponenten.

Warum steinigen? Das ist ein ebenso valider Ansatz wie der mit DB-Komponenten.