SQL Abfragen hardcoded im Quelltext?

[Guest]

Hi,

mein Programm setzt eine Datenbank ein um die nötigen Daten zu bekommen.
Jetzt hätte ich mal eine Frage, wie ihr das mit mit den SQL Abfragen macht. Schreibt ihr die einfach in den Quelltext rein? Das gibt ja das totale Chaos, wenn sich mal was am Datenbank Schema ändert.

Oder gibts da eine bessere Alternative?

 

[ARadauer]

bei kleinen Projekten mach ich das schon, wenn sich meine db struktur ändern, muss ich sowieso meine modell klassen umschreiben, da diese meisten meine tabellen abbilden, da änder ich halt schnell die queries in meinen dao klassen.

bei größeren projekten verwendet man sowas wie hibernate...

 

[SlaterB]

man baut sich eine Art Mapping, irgendwo steht genau EINMAL an zentraler Stelle, dass Java-String x oder Java-Klasse y für DB-Tabelle z steht,
dann kann sich die DB-Tabelle ändern wie sie will, eine Änderung im Programm reicht,
sofern sich alle DB-Anfragen danach richten,

die Umsetzen reicht von einfachen String-Bausteinen in einer Map bis zu riesigen Frameworks wie Hibernate, EJB usw

 

[Gast]

Angenommen ich setze Strings ein, verwendet ihr dann eine Klasse bsp. Constants, die nur die Strings enthält.

Oder habt ihr eine Klasse DatenbankIO die oben die Strings definiert und unten dann gleich die entsprechenden SQL Queries und die Methoden zum Abfragen der DB. So siehts bei mir nämlich momentan aus und die Klasse wird riesig.
Oder lagert ihr die DB Abfrage Methoden in verschiedene Klassen, gegliedert nach Funktionsbereichen, aus und übergebt dieses Klassen das Connection Object?

 

[SlaterB]

Connection-Handling und Konstanten und alles sonst wie allgemeines gehört in separate Klassen,
ersteres sehr wahrscheinlich in eine Basisklasse,

Basisklasse für Klassen, die dann individuelle Operationen enthalten

 

[Gast]

Eh, aus dem Satz werd ich jetzt nicht schlau. Nochmal bitte

 

[SlaterB]

Connection-Handling und Konstanten und alles sonst wie allgemeines gehört in separate Klassen,
ersteres sehr wahrscheinlich in eine Basisklasse,

Basisklasse für Klassen, die dann individuelle Operationen enthalten

 

[Guest]

:shock: Der Satz ergibt für mich keinen Sinn, vielleicht könntest du den bitte nochmal anders formulieren.

 

[SlaterB]

neu formuliert:
ja, die von dir genannten Dinge sind gute Kandidaten für separate Klassen oder Basisklassen

 

[ARadauer]

an Connection Pooling zu denken, ist sicher auch nicht verkehrt ;-)

 

[HoaX]

falls du hibernate einsetzt so gibt es dort bereits "named queries"

 

[maki]

Für kleinere Projekte empfiehlt sich iBatis wenn man kein Hibernate/JPA einsetzen möchte.

Da sind die SQL Statement in XML Dateien gekapselt.

 

[FenchelT]

Ich schreibe meine SQLs haeufig (nicht immer) selbst in eine sep. Datenbanktabelle.

Beim Starten des Programms lese ich diese aus und schreibe sie in dafuer vorgesehene Konstanten.
Wenn sich im Nachhinein herausstellt, dass ein Fehler im SQL vorliegt, muss ich lediglich den SQL in der DB anpassen, ohne dabei das Programm anzupacken und neu zu kompilieren.


Gruesse

 

[maki]

Ich schreibe meine SQLs haeufig (nicht immer) selbst in eine sep. Datenbanktabelle.

Beim Starten des Programms lese ich diese aus und schreibe sie in dafuer vorgesehene Konstanten.
Wenn sich im Nachhinein herausstellt, dass ein Fehler im SQL vorliegt, muss ich lediglich den SQL in der DB anpassen, ohne dabei das Programm anzupacken und neu zu kompilieren.


Gruesse

SQL ist Quellcode, keine Daten, hat weder etwas in der DB zu suchen, noch sollte man den SQL Code einfach so "hintenrum" ändern, ohne dabei einen neuen Release zu machen.

imho

 

[FenchelT]

Ich schreibe meine SQLs haeufig (nicht immer) selbst in eine sep. Datenbanktabelle.

Beim Starten des Programms lese ich diese aus und schreibe sie in dafuer vorgesehene Konstanten.
Wenn sich im Nachhinein herausstellt, dass ein Fehler im SQL vorliegt, muss ich lediglich den SQL in der DB anpassen, ohne dabei das Programm anzupacken und neu zu kompilieren.


Gruesse

SQL ist Quellcode, keine Daten, hat weder etwas in der DB zu suchen, noch sollte man den SQL Code einfach so "hintenrum" ändern, ohne dabei einen neuen Release zu machen.

imho

Definiere Daten

 

[maki]

Definiere Daten

Ähmm... ja klar... wie auch immer.. :roll:

Nix für ungut, aber dieses "Konzept" sollte man nicht weiterempfehlen.

Du brauchst ja auch eine SQL Abfrage um deine SQL Abfragen zu laden... steht die auch in der DB? *g*