Hallo zusammen, hallo @haentschman,
ich habe mir nochmal Gedanken gemacht zum Vorschlag, die
SQL-Abfragen nicht in der Komponente zu speichern.
Dazu stellen sich mir folgende Fragen:
- Würdet Ihr von einer zentralen Stelle mit den
SQL-Queries gleich eine
Query-Komponente zurückgeben oder nur einen
SQL-String für eine Komponente?
Der Vorteil wäre, dass ich beim Wechsel der Datenbank nur an zentraler Stelle die Komponenten-Erzeugung ändern muss und der Kompatibilität wegen aber immer ein TDataSet zurückgeben kann.
Nachteil wäre, dass ich (in der
IDE) keine persistenten Felder mehr nutzen kann, an die ich z.B. Standard-AufbereitungsRoutinen (in OnGetText) hängen kann.
Die Aufbereitung von Feldern z.B. für ein TDBGrid müsste dann auch im Grid erfolgen.
Ebenso müsste ich auf Lookup-Felder verzichten, aber das kann mit einem Join in
SQL ja auch elegant gelöst werden. Nur bei berechneten Feldern sähe es schlecht aus.
- Auf dem Formular würde ich dann auch nur eine DataSource-Komponente anlegen und zur Laufzeit (z.B. im Create) von der zentralen Stelle eine
Query-Komponente anfordern und mit einer DataSource verknüpfen?
- Wie würdet Ihr es mit Parametern für die Anfrage machen? Diese gleich in den
SQL-String mit aufnehmen oder weiterhin als Parameter über ParamByValue und Co. definieren?
Hat das Einfluss auf die Performance der Abfrage, wenn sich die Werte zur Laufzeit ändern können?
Wenn weiterhin Parameter genutzt werden, würdet Ihr diese direkt vom zentralen Querybuilder bestücken lassen (Updates würden dann auch hierüber laufen) oder dies dem Formular überlassen?
- Wenn man den Parameter-Gedanken weiterspinnt, dann wäre es doch sinnvoll, für jede Abfrage eine eigene Routine zu machen, die ein
Query liefert und konkret benannte und typisierte Werte entgegen nimmt. Andernfalls müsste ich immer die Parameter-Namen bzw. -Positionen nachschlagen
Sind meine Gedanken so nachvollziehbar? Oder bin ich da eher auf dem Holzweg?
Viele Grüße
Sneak-L8