Ablage der SQL-Statements

[Andreas H.]

Hallo,

wo legt Ihr eigentlich Eure SQL-Statements ab?

Liegen die bei Euch direkt in der SQL-Property?

Ich hab das für ne Anwendung mal als Konstanten in einer eigenen Unit abgelegt und weise die zur Laufzeit (meistens im OnCreate der Form) zu. Das hat den Vorteil, das man die Statements recyclen kann!

Was meint Ihr dazu?

Gruß Andreas

[hoika]

Hallo,

ich packe die direkt in den Quellcode,
die meine Queries sich häufig ändern
und deshalb meistens dynamisch zusammengebaut werden.


Heiko

[mkinzler]

Alternativ kann mann die Staements auch in der DB ablegen (z.B. als SPs)

[Andreas H.]

Hm, an Stored Procedures hatte ich noch nicht gedacht.

Wie sieht es da mit der Kompatibilität unter den DB-Systemen aus? Ich träume nämlich davon, die Anwendung für möglichst viele Systeme, die von ZEOS unterstützt werden offen zu halten.

Mir geht es dabei ums Recyclen. Deshalb versuche ich so viel wie möglich in Konstanten abzulegen. Das lässt sich auch besser pflegen, vor allem in der Anfangsphase, wenn sich die DB-Struktur oft ändert.

[mkinzler]

Zitat:

Wie sieht es da mit der Kompatibilität unter den DB-Systemen aus?

Sehr schlecht

[Andreas H.]

OK, dann werd ich wohl bei meinen Konstanten bleiben.

Oder gibt es noch andere Lösungen?

[mkinzler]

Aber wenn du dir die Mühe machst für jedes DBMS spezielle SPs zu schreiben, kannst du so etwas Unabhängigkeit schaffen.

[Andreas H.]

Stimmt!

Und zur Zeit kommen nur MySQL und Oracle in Frage.

Ich werde mich in das Thema mal einlesen.

[mkinzler]

Zitat:

Und zur Zeit kommen nur MySQL und Oracle in Frage.

Und warum gerade die?

[Andreas H.]

Na, MySQL für Zuhause und zum Entwickeln und Oracle für die Firma.

Ich schreibe gerade privat an einer Dokumentenverwaltung. Und da es bei uns in der Firma sowas nicht gibt, wird sie wahrscheinlich dort eingesetzt werden. Dort werkelt ein Oracle-Server, bei dem ich einziehen könnte.
Allerdings habe ich die Zusage für eine WAMPP-Installation für Subversion und dann wäre Oracle nicht mehr ganz so wichtig.

Die Dokumentenverwaltung liegt auch hier.
Ist mein erstes größeres Ding mit ner "richtigen" Datenbank.

[Andreas H.]

Ach sch....

ich glaub, ich speichere die SQLs doch in den Komponenten. Ist doch übersichtlicher... :coder:

[mkinzler]

Zitat:

ich glaub, ich speichere die SQLs doch in den Komponenten. Ist doch übersichtlicher...

Kann ich mir nicht vorstellen.
Eine weitee Alternative wäre die Verwendung von mehreren Datenmodulen.

[Bernhard Geyer]

Oder die Verwendung einer abstrakteren DB-Schnittstelle (Bridge-Pattern läßt grüßen). Z.b. Methoden der Art GetAllCustomer, GetCustomerById, ... und erst in der für jeder DB vorhandenen Implementierungsunit wird die passende SQL-Anweisung zusammengebaut. Damit würde man einen DB-Unabhängiger Ansatz ähnlich (N)Hypernate/ECO realisieren.

[mkinzler]

Man könnte den DB-spezifischen Code auch durch ORM kapseln.

[Sir Rufo]

Hallo Andreas,

habe gerade mal kurz in deinen Quellcode geschaut ...

was mir sofort auffiel, war das die GUI-Elemente und die DB-Elemente bei dir in einem Topf liegen (DocsChild.pas).
Nicht nur dass dies völlig gegen ein sauberes Programmierkonzept läuft (Ein-/Ausgabe von der Verarbeitung trennen), sondern es wird dich gerade dann die "Torte im Auge treffen" wenn du unterschiedliche Datenbanken ansteuern möchtest.

Trennst du diese Teile auf, so kannst du die entsprechenden (Verarbeitungs-)Units an die jeweilige Datenbank anpassen und bei Bedarf mitkompiliern und so unterschiedliche Versionen von deinem Programm erstellen (MySQL-, Oracle-, etc. Version).

Denkbar wäre ja auch die Kapselung in einer DLL und diese dann beim Programmstart dynamisch einbinden (welche DB hätten Sie denn gerne).

Zudem kann bei so einer Trennung auch die Programmierung sehr schön auf mehrere Personen verteilt werden (GUI, DB1, DB2 ... )

cu

Oliver

(PS: Ich weiss das so gut, weil ich noch einige Alt-Projekte hier rumliegen habe, wo ich das nicht beachtet hatte und jetzt muss ich diese anpassen - :mrgreen: )