DeleteSQL

[Sir Rufo]

Es ist immer ganz wichtig so wenig Query-Komponenten zu verwenden, wie nur irgend möglich. Am Besten nur eine verwenden, dann hat man das Golden Ring-Anti-Pattern perfekt umgesetzt.

Zitat:

One Query-Component to rule them all.

Dieser Unfug ist tatsächlich sehr verbreitet.

Warum keine PlanungDeleteQuery die fix und fertig da ist und ausschließlich zum Löschen von einem Planungsdatensatz vorhanden ist?

Eine Methode davor gebaut

Delphi-Quellcode:

procedure TMyDataModule.DeletePlanung( PlanungID: Integer );
begin
  PlanungDeleteQuery.ParamByName( 'ID' ).Value := PlanungID;
  PlanungDeleteQuery.ExecSQL;
end;

Evtl. viel zu einfach und zu sehr straight forward ...

[p80286]

@Sir Rufo
DRY?
Warum für 50 Fragestellungen 50 Querys definieren wenn 50 x SQLText reicht?

Gruß
K-H

[Sir Rufo]

Zitat von p80286:

@Sir Rufo
DRY?
Warum für 50 Fragestellungen 50 Querys definieren wenn 50 x SQLText reicht?

Gruß
K-H

Wegen Prepared Statements => Performance?

Hier haben wir es allerdings mit einem SuperGAU zu tun. Die Query wird zur Anzeige von Daten verwendet und wird dann mal flugs umgebaut. Da kräuseln sich einem die Nackenhaare.

[Luckner]

Danke für die Unterstützung. Habe eine weitere Query eingesetzt (wie Sir Rufo vorgeschlagen hat) und es funktioniert. Denke auch, für solche Aufgaben ist eine weitere Query schon nicht schlecht.

Danke.

[frankyboy1974]

Hallo,

ich möchte hier mal antworten:


Ich benutze in meinem eigenem Persistenz-Framework grundsätzlich tatsächlich nur eine Query-Komponente. Ob ich nun ein 'Select' oder ein 'Delete' oder was auch immer gegen die Datenbank huste, spielt erst mal keine Rolle. Delphi-Entwickler benutzen gerne für jede Abfrage ein neues Query-Objekt, eins sollte grundsätzlich reichen, lässt man Nebenläufigkeit jetzt erst mal aus dem Spiel.


mfg

frank

[jobo]

Zitat von frankyboy1974:

Ich benutze in meinem eigenem Persistenz-Framework grundsätzlich tatsächlich nur eine Query-Komponente. Ob ich nun ein 'Select' oder ein 'Delete' oder was auch immer gegen die Datenbank huste, spielt erst mal keine Rolle. Delphi-Entwickler benutzen gerne für jede Abfrage ein neues Query-Objekt, eins sollte grundsätzlich reichen, lässt man Nebenläufigkeit jetzt erst mal aus dem Spiel.

Also
1. Benutzt der TE sehr wahrscheinlich nicht Dein Persistenzframework
und
2. haben wir hier die Situation, dass die betreffende Query Teil (property) einer Datasetkomponente ist, die einen speziellen Zweck erfüllen soll.
Summa summarum macht es an der Stelle keinen Sinn, die "Schwesterproperty" für das Dataset zu vergewaltigen und dort das Delete einzutragen und auch nicht unbedingt eine separate Query zu erfinden, die im Delete Fall durchführt, wofür es eine vorgesehene Methode gibt. Standard Code, der per Dataset.Delete arbeitet, dürfte an der Stelle sonst auch nicht funktionieren.

[Sir Rufo]

@frankyboy1974

So gekapselt und von der weiteren Verwendung versteckt kann man das auch ruhig machen.

Hier wurde aber gerade gezeigt, dass ein DataSet, was aktiv für die Anzeige eines Grid zuständig ist auch mal eben flugs für das Absetzen eines Statements missbraucht wird.

Und wenn du dein Framework passend aufgebaut hast

Delphi-Quellcode:

TFramework = class
private
  FGoldenRingQuery : TQuery;
protected
  // Bereitet die Query für den Abfrage-Kontext vor
  function GetQuery( const QueryContext: string ): TQuery;
end;

dann ist es ja auch ein Leichtes, hier ein Dictionary aufzusetzen, was dann für jeden Abfrage-Kontext eine eigene Query-Konponente zur Verfügung stellt und vorhält.

Falls es nämlich mal zu zeitlichen Engpässen kommen sollte (viele Operation mit ständig wechselndem Query-Kontext). Denn bei jedem Zuweisen des SQL-Textes wird dieser immer wieder geparst, um die Parameter herauszufinden.