![]() |
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 |
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 |
Re: Ablage der SQL-Statements
Alternativ kann mann die Staements auch in der DB ablegen (z.B. als SPs)
|
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. |
Re: Ablage der SQL-Statements
Zitat:
|
Re: Ablage der SQL-Statements
OK, dann werd ich wohl bei meinen Konstanten bleiben.
Oder gibt es noch andere Lösungen? |
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.
|
Re: Ablage der SQL-Statements
Stimmt!
Und zur Zeit kommen nur MySQL und Oracle in Frage. Ich werde mich in das Thema mal einlesen. |
Re: Ablage der SQL-Statements
Zitat:
|
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 ![]() Ist mein erstes größeres Ding mit ner "richtigen" Datenbank. |
Re: Ablage der SQL-Statements
Ach sch....
ich glaub, ich speichere die SQLs doch in den Komponenten. Ist doch übersichtlicher... :coder: |
Re: Ablage der SQL-Statements
Zitat:
Eine weitee Alternative wäre die Verwendung von mehreren Datenmodulen. |
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.
|
Re: Ablage der SQL-Statements
Man könnte den DB-spezifischen Code auch durch ORM kapseln.
|
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