SQLBuilder (nonvisual)

[schlecki]

Hallo,

ich suche einen SQLBuilder. Aussehen sollte das in etwa so:

Delphi-Quellcode:

  stm := TSQLStatement.Create();
  stm.Select('Field1')
     .Select('Field2')
     .From('Table')
     .Where(TCriteria.Create()
       .Criteria('Field1').EQ('test'))
     .OrderBy('Field2')

das Ergebnis sollte dann so aussehen:

Code:

  select Field1, Field2 from Table where Field1 = 'test' order by Field2

Hat jemand sowas schonmal gesichtet oder vlt sogar selbst gebaut?

Gruß
schlecki

[s.h.a.r.k]

Habs mal in PHP gesehen, aber unter Delphi leider noch nie. Hab es schon mal selbst probiert, aber war mir dann zu kompliziert. Bin daher sehr schnell auf eine "normale" Query umgestiegen, d.h. halt einen String geschrieben. Das ist auch schneller änderbar imho.

[Bernhard Geyer]

Es gibt doch auch ein paar OR-Mapper-Frameworks für Delphi. Wurde hier im Forum schon öfter verlinkt.

[Neutral General]

Mal eine ganz blöde Frage nebenbei: Wofür soll sowas gut sein? :gruebel:

[s.h.a.r.k]

Ist ganz nett, wenn man nicht selbst den Query-String aufbauen will, aber eigentlich reine Bequemlichkeit :wink: Aber sobald man an etwas komplexere Queries stößt ist das Konzept eher umständlich.

[schlecki]

Ich habe hier eine, nun, gewachsene Anwendung. Da stehen so tolle sachen drin wie:

Delphi-Quellcode:

  Query := TQuery.Create(nil);
  
  Query.SQL.Add('select');
  Query.SQL.Add('  *');
  Query.SQL.Add('from');
  Query.SQL.Add('  table');
  Query.SQL.Add('where');
  Query.SQL.Add('  1 = 1');
  Query.SQL.Add('order by');

{ ... viel später }
  Query.SQL[1] := 'third.field1, second.field2, table1.*';
  Query.SQL[3] := 'table1, table3 third, table4 second';
  Query.SQL[5] := 'table1.field = third.field and second.field2 = table1.field3';
  AddRightCondition(Query.SQL, {...});
  Query.SQL.Add('table1.field');

Mit diesen Objekten könnte man das mMn besser auseinandernehmen und ordnen.

Einen kompletten OR-Mapper kann ich hier nicht einsetzen. Mit dem Builder, wie er mir vorschwebt könnte man einzelne Bereiche der Query dann leichter modifizieren und am Schuß das SQL erzeugen lassen.

Naja, mal sehen, vlt werd ich da mal was zu bauen ;)

[s.h.a.r.k]

Daher hasse ich diese TTable, TDataSource und was weiß ich noch alles... Einmal eine Query ausführen, die Daten in Objekte gießen und gut ist das ganze. Wenn ich was einfügen/updaten will, dann muss ich halt neben der Query auch noch die Daten weiterreichen und ab damit an die Datenbank.

[schlecki]

das hat doch hier nix mit TTable oder TDataSource zu tun?!

[webcss]

Das sieht aus wie LINQ unter .NET.
In der DeHL Library ist eine Klasse bzw. Interface enthalten, die LINQ-ähnliches verhalten bereitstellt. Anzuwenden allerdings auf Listen usw.

Im Rahmen eines ORM macht ein solcher QueryBuilder auch durchaus Sinn, aber in einer Anwendung welche auf TDataset und Konsorten basiert reicht ein FilterBuilder(=baut ein WHERE Statement zusammen) vollkommen aus. Denn kann man sich schnell selbst basteln, hab ich für mein ORM auch gemacht.

PS: macrobject's dobject hat das so gelöst wie Du Dir das vorstellst...

[rokli]

Hi Schlecki,

ich schreibe soetwas dauernd ... aber wenn Du einer Function / Procedure die Feldnamen sowieso mitgeben musst, kannst das ganze doch gleich in einer Oberfläche macht.

Sonst kannst Du doch sowieso nur die gesamte Feldliste "automatisch" in das SQL Statement einlesen lassen; und wie siehts mit der WHERE Clause aus, woher bekommst Du die? Wie willst Du denn den ORDER definierten, wenn nicht manuell??

Mittlerweile schreib ich mir immer noch ein paar Zeilen dazu, damit ich die Statements speichern und auch wieder per Progi öffnen kann.

Gruß
Rolf

[schlecki]

dobjects hab ich schon mal gesehen - hier gehts allerdings wirklich nur um das zusammenbauen des SQL-Strings (teilweise verteilt über mehrere Funktionen und viele if's).

Und da wollte ich jetzt weg von dem Zusammenbauen des Strings, weil der dann teilweise wieder geparst werden müsste, welche Bedingungen schon drin sind. Bei so einem Konstrukt könnte man die Objekte schöner befragen, ob die Bedingung schon existiert, ggf ändern und so weiter.

In dem Projekt ist leider noch D2007 im Einsatz - somit kommt DeHL leider nicht infrage - aber ich werds mir mal anschauen, vielleicht kann ich ja was rausziehen ;)

@Rolf:
Sowohl die Liste der zu selektierenden Felder als auch die Felder, die im Where angesprochen werden, variieren - es kommen hier einige Parameter, die "von außen" reingereicht werden.

[mschaefer]

Also wenn man 'Anwendungen mit Umsortierung der Datenmenge, Feldreihenfolge und Einschränkungen bei Where und eventuell selektierbarer Gruppierung entwickelt machen die Dinger Sinn. Aber man muß sich mit der Systematik länger beschäftigen.

Felder mit fester Position
Felder mit variabler Position

Feste Felder in der Sortierung
Ergänzende Felder in der Sortierung

Statische Where-Bedingung (Master Detail Referenzfelder)
Where Bedingung aufgrund Nutzereinschränkungen

Erlaubte Gruppierung
Sum Mean Max Min kalkulatorische Variablen versus Gruppenvariablen

Leider ist mir in Delphi da nichts fertiges bekannt.

Grüße

[mkinzler]

DeHL
ActiveQueryBuilder (free Edition)