Fragen zur DB-Programmierung

[Stinner]

Hallo,
habe zwei generelle zusammenhängende Fragen zum DB-Design bzw. zur Datenbankprogrammierung
bzw. Frage ich mich, ob meine Ansätze "richtig" sind.

Wenn ich eine Datenbank habe und dann ein Java Programm schreibe, welches diese DB nutzt, soll
man das Programm ja in die 3 Schichten (DB,Apllikation, Präsentation) aufteilen.

Auf die DB schicht gehören ja dann offensichtlich sachen, wie das starten und beenden der DB, Veränderungen der Einstellungen der DB usw..
Wie ist es aber mit Abfragen? Ich habe das so gemacht, dass ich eine Methode zur Verfügung gestellt habe, die ein SQL-String übergeben bekommt und das Ergebnis zurück gibt? Also man hat keine spezifischen Abfragen?

Das bringt mich dann zur nächsten Frage. Wenn ich das so mache wie oben. Dann baue ich ja quasi auf der Applikationsebene Abfragen zusammen und gebe die Strings nach unten.
Was mache ich aber dann mit dem Ergebnis? Man bekommt ja ResultSets zurück. Normalerweise würde ich die Daten in Objekte schreiben. Aber dauert es nicht zu lange, wenn die Abfrage viele Daten zurück gibt? Momentan arbeite ich immer nur mit StringArrays, was aber nicht dem Gedanken der OO entrspricht?
Felix

 

[SlaterB]

mache es so wie es für dich Sinn ergibt, von selbst kann man derartige Konzepte kaum entwickeln,
da müsstest du bei großen Projekten abschauen

allgemein sollte man an außerhalb der DB-Schicht weder SQL noch ResultSet kennen, sondern Methoden wie
List<Person> list = dbLoader.ladePersonenMit(name, alter);
anbieten

Zeit und Aufwand sind sekundär wenn es nicht bemerkbar wird, 2 GHz und 2 GB Speicher wollen auch genutzt werden

 

[Stinner]

Hi,
wollte halt mal wissen, wie so generell die Meinungen sind. Wie gesagt, auf meiner Applikationsebene stelle ich momentan so Methoden bereit.
In der Methode würde ich aber ja dann einen SQL String haben, den ich an die DB-Schicht gebe, erhalte z.B. einen ResultSet zurück und gebe die Ergebnisse von der Methode in einem Array/List etc. weiter.

Aber die Liste von Personen ist für mich problematisch. wiel dann müsste ich ja für jede Zeile aus dem Ergebnis meiner Abfrage ein Objekt erzeugen. das dauert meiner Meinung nach lang, bringt aber im Programm Verlauf viele Vorteile, da ich nicht mit Strings sonderen Objekten arbeite.

 

[SegFault]

Die Frage ist, wie aufwendig willst du das machen? Ich würde an deiner Stelle schon komplette Objekte erzeugen. Du kannst es per JDBC von Hand machen oder du nutzt Frameworks dafür (Hibernate kann ich da nur empfehlen, arbeite mich auch damit ein) im grunde kann man mit Hibernate gleich komplette Klassen auf eine DB Mappen oder umgekehrt. (Datenbankschema in Klassen umwandeln). Dann bietet es einfache methoden um listen von diesen Klassen zu laden, zu Speichern etc. Leider ist es weniger für Stand Alone Applications geeignet (Man kann selbst keine wirklich nutzerverwaltung auf DB Ebene damit machen, da der Login direkt im config file angegeben ist) da müsste man sozusagen noch eine Schicht einziehen DB-Application Server-Application Client-GUI dafür wird das ganze noch eine nummer sicherer weil der App Server alle zugriffe auf die DB abschirmt. Wenns aber nur für ein kleines Privates Projekt wäre, ist das ganze dann eher overhead wo ich dann wieder zu nativer JDBC Programmierung tendieren würde.

 

[musiKk]

Auf die DB schicht gehören ja dann offensichtlich sachen, wie das starten und beenden der DB, Veränderungen der Einstellungen der DB usw..

In Deinem Programm kümmerst Du Dich nicht um das Starten und Beenden der Datenbank. Das wird als gegeben hingenommen. Ein Java-Programm kümmert sich ja schließlich auch nicht darum, ob der Netzwerkstack läuft, bevor es auf Ressourcen in einem Netzwerk zugreift. Der Datenbankadministrator muss kein Programmierer sein.

Wie ist es aber mit Abfragen? Ich habe das so gemacht, dass ich eine Methode zur Verfügung gestellt habe, die ein SQL-String übergeben bekommt und das Ergebnis zurück gibt? Also man hat keine spezifischen Abfragen?
[...]
Dann baue ich ja quasi auf der Applikationsebene Abfragen zusammen und gebe die Strings nach unten.
Was mache ich aber dann mit dem Ergebnis? Man bekommt ja ResultSets zurück.

Die Anwendungsebene sollte keine Kenntnisse über die Datenbank haben. Sie soll keine Queries bauen und keine ResultSets interpretieren. Die Datenschicht bietet häufig Methoden für Anfragen und erzeugt aus den Ergebnissen Objekte (aus dem Modell), die in Anwendungs- und Darstellungsschicht verwendet werden können. Du kannst Dir mal etwas zum DAO anschauen. Auf diese Weise werden die Schichten voneinander entkoppelt.

 

[bronks]

... Leider ist es weniger für Stand Alone Applications geeignet (Man kann selbst keine wirklich nutzerverwaltung auf DB Ebene damit machen, da der Login direkt im config file angegeben ist) ...

Doch, doch kann man. Erst vor kurzem ging es hier um das Thema. Insgesamt rate ich davon ab, dem Benutzer Zugriff auf die DB zu geben, außer nur lesend. Da finden sich zu oft ein paar Schlaumeier, die mit Datenbankwerkzeugen ansatzweise umgehen können und dann auf der Datenbank Mist machen. Zwar dürfen Sich diese dann einen neuen Job suchen, aber es gibt zu viele Spinner.

 

[bronks]

Zum eigentlichen Thema kann ich das Empfehlen: Core J2EE Patterns: Patterns index page . Es steht zwar J2EE in der Überschrift, aber eigentlich ist es allgemeingültig. Je nach Anwendungsfall läßt man ein paar wirklich unnötige Sachen weg, aber sonst macht man nichts falsch, wenn man sich grundlegend daran hält.