ADOQuery - SQLQuery ??

[Jumpy]

Ich lagere die SQl-Statements immer in Funktionen aus, da kann ich mir dann dort aussuchen, ob ich die von extern Lade oder im Quelltext zusammen baue.

Delphi-Quellcode:

procedure DeleteCurrentUser;
var q:TAdoQuery;
begin
  q:=TAdoQuery.Create(self);
  q.Connection:=Con;
  q.SQL.Text:=SQL_DeleteCurrentUser;
  try
    q.ExecuteSQL;
  finally
    q.free;
  end;
end;

function SQL_DeleteCurrentUser:String;
var s:TSQL;
begin
  s := TSQL.Create;
  s.Add := 'Delete From ' + TabelleUser;
  s.Add := 'Where ID = ' + CurrentID;
  Result:=s.Text;
  s.free;
end;

Für das Beispiel mal ohne Parameter. TSQL ist eine Stringlist mit ein paar Extras und .Add ist als Property angelegt, weil ich das mit den Klammern nicht so schön lesbar finde ".Add('Select...)".

[haentschman]

Moin...

Zitat:

Bei 'nem effen Select * from Tabelle mag Text ausreichen, aber bei etwas größeren und verschachtelten Statements ist eine (halbwegs) ordendliche Formatierung auch nicht zu verachten

...ja logisch. Ich spreche nur von der ersten Zeile...statt Clear+Add zu Text. Später heraus ist es legitim das Add, wegen der Formatierung, zu benutzen.

!!!Eigenwerbung:
@Jumpy, @p80286, @nahpets:
Früher habe ich auch die Statements im Quelltext angelegt. Die Statements waren nicht direkt 1:1 testbar (wegen Text, Add & Co.) Dann habe ich Ressourcen endeckt und komplett ausgelagert.
Tutorial:
http://www.delphipraxis.net/49505-sq...einbinden.html
SQLCreator:
http://www.delphipraxis.net/190316-d...e-creator.html

[nahpets]

Zitat von haentschman:

!!!Eigenwerbung:

Hihi, kann ich auch:

Bei mir liegen für gewöhnlich alle Statements in eine Datenbanktabelle.

Lediglich das Statement zum Holen der Statements ist "fest verdrahtet".

Dadurch kann ich die Statements erstmal "ausprobieren". Jedes hat 'ne eindeutige ID, über die es angesprochen wird.

Parameter sind natürlich möglich, sowohl die SQL-Stringlistentypischen Doppelpunkt-Parameter, als auch die für ein Format erforderlichen %-Parameter. Selbst Kombinationen funktionieren.

Und bei 'nem Datenbankwechsel muss nur in dieser Tabelle die Syntax entsprechend den Anforderungen der Datenbank angepasst werden (soweit überhaupt erforderlich).

Typ(ück)isches Beispiel:

Select first 10 * from Tabelle Select top 10 * from Tabelle Select * from Tabelle where RowNum <= 10
Oder mal heißt es IsNull, dann mal IfNull oder Nvl oder Coalesce ...

Oder mal ||, um VarChars "zusammenzupappen" oder halt eben mit + ...

Wenn irgendmöglich, liegt das alles in der Datenbank und zwar so, dass es für das Programm absolut transparent ist.

"Datenbankwechsel?"
"Nagut, wenn Sie meinen. Daten in neue Datenbank kopieren, Tabelleninhalt anpassen und geht." (fast immer)

Bei mandandenfähiger Software ist es dann besonders schön, wenn für unterschiedliche Mandanten unterschiedliche Datenbanken genutzt werden, die Anwender aber nur eine Exe haben, die per Auswahldialog zwischen den Mandanten wechselt. Der Rest geht für Anwendung (und natürlich auch den Anwender) absolut transparent.

Zugegeben: Sowas musste ich bisher nur einmal bauen.

[haentschman]

Zitat:

Hihi, kann ich auch:

Der Möglichkeiten gib es verschiedene. Das Auslagern ist aus dem Quelltext ist das Entscheidende.

PS: Bei deiner Variante hätte ich Bauchschmerzen immer an die Datenbank dran zu müssen. Beim Einspielen einer früheren Sicherung könnte die EXE nicht zu den Statements passen.

Wenn wir weiter darüber diskutieren wollen, sollten wir das in einen separaten Thread auslagern.

[nahpets]

Zitat von haentschman:

PS: Bei deiner Variante hätte ich Bauchschmerzen immer an die Datenbank dran zu müssen. Beim Einspielen einer früheren Sicherung könnte die EXE nicht zu den Statements passen.

Richtig, und die übrigen Daten sind dann genauso veraltet.

Zuerst kommen die fertigen und durchgetesteten Statments in die Datenbank und dann die Daten.
Die erste Sicherung enthält damit immer die zur Datenbank passenden Statements. Eine veraltete Version gibt es nicht (es sei denn, irgendwer daddelt später noch an den Statements rum. Der bekommt dann aber Haue).
Davon abgesehen werden die Statements immer auch noch als Scripte zu den Quelltexten der Software gelegt (und ggfls. damit zusammen versioniert).

Ok, das ist ein vielfältiges Thema, über das man andernorts sicherlich mal 'ne "Grundsatzdiskussion" führen könnte, um ggfls. aus den bisher "erfundenen" Konzepten ein "allumfassendes" zu machen, das alle Vorteile der bisherigen Konzepte vereinigt und alle Nachteile ebendieser eleminiert.

[p80286]

Zitat von nahpets:

Dadurch kann ich die Statements erstmal "ausprobieren". Jedes hat 'ne eindeutige ID, über die es angesprochen wird.

Im Prinzip gefällt mir der Ansatz, nur der Zugriff über die wenig sprechende ID gefällt mir nicht. Aber bei deskriptiv hat wieder jeder andere Ideen.

Gruß
K-H

[nahpets]

Die ID schien mir das Sinnvollste für den Zugriff aus 'nem Programm zu sein.

In der Datenbanktabelle steht neben ID und SQL auch noch 'ne Beschreibung zum SQL, so dass man dort auch noch Sinn und Zweck nachlesen kann, ohne erstmal das Statement zu analysieren.

Im Programmquelltext steht an den Stellen, an denen ein Statment aus der DB geholt wird, immer auch ein entsprechender Kommentar (soweit sich nicht aus dem Quelltext bereits ein eindeutiger Hinweis ergibt).

Ein

Delphi-Quellcode:

qry.SQL.Text := GetSQLStatement(42);
qry.Open;
...

ist ein absolutes NoGo.

Entweder das ist in einer Prozedur oder Funktion mit einem sprechenden Namen gekapselt oder davor steht ein Kommentar.

Mindestens

Delphi-Quellcode:

// vollständige Lieferantenliste anzeigen.
qry.SQL.Text := GetSQLStatement(42);
qry.Open;
...

Für jemanden, der den Quelltext erstmalig liest, dürfen keine Fragen offen bleiben.

Wenn der erst in der Datenbank nachschauen muss, was für ein Statment denn da geholt wird, ist etwas grundlegend falsch.

[p80286]

Wie wäre es mit

Delphi-Quellcode:

const
  GETPERSONLIST=42;

.....
qry.SQL.Text := GetSQLStatement(GETPERSONLIST);
qry.Open;
 ...

Gruß
K-H

[nahpets]

Klar, kann man so machen.

Habe da mal 'ne eigene Klasse, abgeleitet von einer Datenbankkomponente gemacht. Die Klasse hatte u. a. die Attribute InsertID, UpdateID, DeleteID und SelectID. Dort stand dann die entsprechende ID.

Dann gab es die passenden Methoden dazu.

Von dieser Klasse waren dann die weiteren Klassen für Kunden ... abgeleitet. Sie hatten zusätzlich dann die entsprechend Attribute wie Name ...

Als Programmiere musste man für's Select dann nur noch die Get-Methode aufrufen. Für neue Daten halt New, Update ging über Set und Delete setzte nur einen Löschschalter und Löschdatum ... im Datensatz, da keine Daten physikalisch aus der Datenbank entfernt wurden.

Eigentlich war das für den Entwickler sehr transparent.

Er musste sich weder um die Zuweisung der Tabelleninhalte in die Attribute kümmern, noch um den umgekehrten Weg.

Das Einzige, was er machen musste, war: Die Inhalte der Attribute in die Anzeigemaske bringen bzw. die Inhalte der Anzeigemaske wieder in die Attribute der Klasse schieben.
Dafür waren die passenden Getter und Setter angelegt.
Und er musste natürlich, soweit erforderlich, die entsprechende Geschäftslogik und ggfls. Plausibilitätsprüfungen ..., implementieren.

Die Basisklasse war schon recht kompliziert und funktionierte zum Teil über RTTI, aber die Benutzung im Programm war dann beinahe schon banal einfach.

Schon interessant, was man mit RTTI und sinnvoller Vererbung für "schöne Schweinereien" machen kann. Da sieht man dann, wie leistungsfähig einen vernünftige Objektorientierung sein kann.