Generelles zu SQL Queries

[HCB]

Hallo,
ich wollte mal gerne von euch Profis wissen, wie ihr es generell mit den SQL-Abfragen handhabt. So wie ich das sehe, gibt es zwei Möglichkeiten:
1. Ich gebe die Abfrage im Quelltext direkt ein wie

Delphi-Quellcode:

FDQuery1.close;
  FDQuery1.sql.Clear;
  FDQuery1.sql.Text:='SELECT 'Select * from Table';
  FDQuery1.Open;

oder ich gebe die SQL-Query direkt im Firedac-Query Abfrageeditor ein. Dann brauche ich im Quelltext nur FDQuery.Open einzugeben und die Query wird automatisch beim Öffen ausgeführt.

Welche Methoden verwendet ihr?
Was sind die Vor- und Nachteile der jeweiligen Möglichkeit in Bezug auf Performance, Übersichtlichkeit, Flexibilität, Speicherauslastung etc.?

Wäre sehr nett, wenn Ihr euere Meinung dazu mitteilen würdet.

LG Harry

[haentschman]

Hallöle...

Zitat:

ich wollte mal gerne von euch Profis wissen, wie ihr es generell mit den SQL-Abfragen handhabt.

...da gibt es einige Methoden. Je nach Anwendungsfall...

[meine Meinung]
1.
- Die Datenbank wechseln ... Access
(Access ist bekannt dafür, das der "SQL Standard" nicht immer funktioniert)
- Kostenlose Variante: ZEOS mit Firebird (Embedded und Server...klein aber fein)
2.
- Persönlich speichere ich meine SQL Statements als Dateien in einem Ordner.
- Die SQL werden als Ressource, wie Text, eincompiliert. https://www.delphipraxis.net/49505-s...einbinden.html

Vorteile:
- keine SQL Add Orgien bei Eingabe im Quelltext (Add nur beim Zusammenbauen)
- Die SQL Statements sind besser testbar, weil normaler Text, statt in der DFM als Strings.
- SQL Statements können "zusammengebaut werden".
- Mehrfachverwendung einzelner SQL in verschieden Projekten durch Datei basierte Ablage
- Unterstützung von verschiedenen Datenbanken mit unterschiedlichen SQL "Dialekten" über separate Units oder Interfaces (nebeneinanderlegen der SQL bei verschieden DBMS - Vergleich)
Beispiel: Firebird kennt "returning" MSSQL macht das anders...
- einfacher Wechsel der Zugriffskomponenten, weil unabängig vom SQL (nicht in DPR verankert)
- Die SQL Dateien liegen in der Versionsverwaltung und können unabhängig vom Quelltext von einem Datenbankprofi geändert werden.

Beispiel SQL:

Delphi-Quellcode:

function TDatabase_FB.GetSQLByName(SQLName: string): string;
var
  SQLStream: TResourceStream;
  SQLStrings: TStringList;
begin
  Result := '';
  SQLStrings := TStringList.Create;
  try
    SQLStream := TResourceStream.Create(HInstance, SQLName, PWideChar(conDatabaseResourceGroupString[FDatabaseProperties.DBMS]));
    try
      try
        SQLStrings.LoadFromStream(SQLStream);
        Result := TTools.Decrypt(SQLStrings.Text, conKey);
      except
        Result := '';
      end;
    finally
      SQLStream.Free;
    end;
  finally
    SQLStrings.Free;
  end;
end;
...
function TDatabase_FB.CreateQuery: TUniQuery;
begin
  Result := TUniQuery.Create(nil);
  Result.Connection := FConnection;
end;
...
var
  Query: TUniQuery;
begin
  Query := CreateQuery;
  try
    Query.SQL.Text := GetSQLByName('CLI_PLANT_SCHEME');
    Query.ParamByName('PID').AsInteger := PlantID;
    Query.Open;
    while not Query.Eof do
    begin

- https://www.delphipraxis.net/190316-...e-creator.html
- https://www.delphipraxis.net/49505-s...einbinden.html

Grundsätzlich:

Delphi-Quellcode:

MyQuery.Close; // nicht immer nötig
MyQuery.SQL.Clear; // nicht nötig, weil ".Text" das automatisch macht
MyQuery.SQL.Text := 'SELECT 'Select * from Table''; // falsch "select * from Table" oder mit Parameter "select FeldName from Table where SearchField = :PAR"
MyQuery.ParamByName('PAR').AsString := 'Bla'; // immer Parameter verwenden wenn gebraucht
MyQuery.Open;

[meine Meinung]

[mlc42]

Es kommt darauf an was man machen möchte.
Wenn man kleine einfache SQL Abfragen oder ein Query für diverse Zwecke
benutzt oder den SQL Ausdruck immer wieder komplex anders aufbauen muss
kann man das besser im Quellcode machen.
Bei relativ statischen SQL´s die Parameter vewenden z.B.: 'SELECT * FROM TABLE WHERE DATUM=ATUM'
mach ich das meist im Designer.
Zur Laufzeit muss man dann nur noch die Params mit ParamByName('DATUM').AsDateTime
setzen. Das hat den grossen Vorteil das man sich nicht selbst um Formate kümmern
muss. Das macht dann FireDAC selbst. Das ist auch die empfohlene Methode bei FireDAC.

Man kann das aber ebenfalls im Quellcode lösen. Die Performance dürfte das in den meisten Fällen
nicht groß beeinflussen.
Params mit Prepare zu benutzen ist etwas schneller.

[haentschman]

Grundsätzlich Parameter benutzen!
https://de.wikipedia.org/wiki/SQL-Injection

[HCB]

Vielen Dank für euere Tipps. Das Programm arbeitet im lokalen Netz mit 5 Usern, da hat keiner irgendwelche Programmierkenntnisse.
Das mit den Parametern verstehe ich wenn es sich um eine datenbank im Internet handet. Aber ist es in meinem Fall wirklich nötig?

LG Harry

[Christian Seehase]

Moin Harry,

ich finde man sollte sich immer daran gewöhnen die sichere Variante
zu verwenden. Es muss ja nicht mal jemand mit bösem Willen handeln.
Wenn es schlecht läuft, wird, versehentlich was aus der Zwischenablage
eingefügt und abgeschickt, was auch immer dabei dann herauskommt.
Ausserdem, finde ich, ist die Variante mit Parameter besser zu lesen und
somit wartbarer.

Ein ausführlicher Artikel zum Thema SQL-Injection
SQL Injection Prevention Cheat Sheet

Auch wenn man Resourcen belegt, sollte das nächste was man schreibt, die Freigabe der
Resourcen zu schreiben, damit man es nicht vergisst.

[hes]

Warum eigentlich so eine alte Access? Die hatte ich auch vor ca. 20 Jahren im Einsatz, aber bei mehreren Usern was eintragen war immer mal wieder der Index kaputt und man musste reparieren. Danach wurde eine mySQL genommen und ich hatte nie wieder Probleme. Heute würde ich MariaDB, SQLite wenn man keine Serverinstallation möchte oder eine msSQL nehmen.

[HCB]

Ja Leute ich weiß, Access ist veraltet.
Da ich in unserer Firma aber eine WaWi mit einer Access Datei habe und Funktionen brauche, die nicht in der WaWi vorhanden sind, bin ich eben darauf angewiesen Abfragen zu schreiben, die auf die Access-Datei zugreifen z.B. Auswertungen etc.
Ich wüsste nicht, wie ich auf z.B. auf eine MariaDB umstellen soll, wenn die alte WaWi nach Access .mdb sucht. Eine komplett neue WaWi zu entwickeln, mit einer altuellen DB-Server Variante, ist völlig ausgeschlossen.

LG Harry