Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Ablage der SQL-Statements (https://www.delphipraxis.net/98666-ablage-der-sql-statements.html)

Andreas H. 30. Aug 2007 17:38

Datenbank: MySQL • Version: 5 • Zugriff über: ZEOS

Ablage der SQL-Statements
 
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 30. Aug 2007 17:59

Re: Ablage der SQL-Statements
 
Hallo,

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


Heiko

mkinzler 30. Aug 2007 18:20

Re: Ablage der SQL-Statements
 
Alternativ kann mann die Staements auch in der DB ablegen (z.B. als SPs)

Andreas H. 30. Aug 2007 18:35

Re: Ablage der SQL-Statements
 
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 30. Aug 2007 18:39

Re: Ablage der SQL-Statements
 
Zitat:

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

Andreas H. 30. Aug 2007 18:49

Re: Ablage der SQL-Statements
 
OK, dann werd ich wohl bei meinen Konstanten bleiben.

Oder gibt es noch andere Lösungen?

mkinzler 30. Aug 2007 18:52

Re: Ablage der SQL-Statements
 
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. 30. Aug 2007 19:05

Re: Ablage der SQL-Statements
 
Stimmt!

Und zur Zeit kommen nur MySQL und Oracle in Frage.

Ich werde mich in das Thema mal einlesen.

mkinzler 30. Aug 2007 19:07

Re: Ablage der SQL-Statements
 
Zitat:

Und zur Zeit kommen nur MySQL und Oracle in Frage.
Und warum gerade die?

Andreas H. 30. Aug 2007 19:27

Re: Ablage der SQL-Statements
 
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. 30. Aug 2007 21:42

Re: Ablage der SQL-Statements
 
Ach sch....

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

mkinzler 31. Aug 2007 07:29

Re: Ablage der SQL-Statements
 
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 31. Aug 2007 07:40

Re: Ablage der SQL-Statements
 
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 31. Aug 2007 07:42

Re: Ablage der SQL-Statements
 
Man könnte den DB-spezifischen Code auch durch ORM kapseln.

Sir Rufo 31. Aug 2007 08:44

Re: Ablage der SQL-Statements
 
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: )


Alle Zeitangaben in WEZ +1. Es ist jetzt 18:18 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz