Kapselung Tabellen der Datenbank erzeugen.

[Meeresgott]

Hallo,

ich habe eine Klasse in der ich die java.sql.Connection und das java.sql.Statment initzialiesire

ich habe eine Klasse in der ich die Initialisierung der java.sql.Connection und des java.sql.Statments vornehme.
Dies mache ich in einer Methode connect() diese überprüft auch ob alle Tabellen die ich brauche auch schon in der Datenbank drin Sind wenn nicht werden sie durch den Aufruf einer anderen Methode der selben Klasse erzeugt.

Fast jede Tabelle hat eine eigen Klasse die sich um das jeweilige Handling kümmert.

Ist es nicht besser das die Klassen, die sich um das Handling kümmern überprüfen ob die Tabellen schon da sind und sie ggf. erzeugen ? oder macht es Sinn alle Tabellen an der selben Stelle im Code zu erzeugen?

 

[AndyJ]

Ich persoenlich denke, dass Datenbanktabellen gar nicht via Applicationcode erzeugt werden sollten (einzige Ausnahme Datenbankdesigntools). Dein Programm braucht dazu wesentlich mehr Rechte als fuer den Normalbetrieb notwendig, was ein Sicherheitsrisiko darstellt.

 

[Tobse]

Fast jede Tabelle hat eine eigen Klasse die sich um das jeweilige Handling kümmert.

Ist es nicht besser das die Klassen, die sich um das Handling kümmern überprüfen ob die Tabellen schon da sind und sie ggf. erzeugen ? oder macht es Sinn alle Tabellen an der selben Stelle im Code zu erzeugen?

Wenn sich deine Tabellen-Klassen wirklich NUR um die Datenbanktabellen kümmern, ist das IMHO der bessere Ort, ja. Aber generell: es hört sich schwer danach an, als ob du hier einen O/RM nachbaust. DU wärst IMHO mit Lösungen wie Hibernate vieeeeel besser bedient.

P.S.: Im Betrieb sollten DB-Tabellen NIEMALS angelegt werden. Nicht nur, weil es, wie @Meeresgott schon sagte, ein Sicherheitsrisiko ist, sonder auch, weil es schlicht ein Setup-Task ist. Migration von Datenbanken kann man mit Liquibase oder Flyway super managen.

 

[Meeresgott]

Da ich mich nicht vorher einen MySQL Server installieren kann bin ich auf eine kleinere Variante umgestiegen, H2-Database und dachte es wäre einfacher den Code zum erstellen dieser kleinen Datenbank in meinem Programm unterzubringen.
@Tobse Also würdest du mir raten einen kleinen Installer zu schreiben der die Datenbank vorkonfiguriert und mein Hauptprogramm dann auf die schon fertig angelegte Datenbank "loslassen"?

 

[Thallius]

Richtig...

das ganze nutzt aber nur dann etwas, wenn dein installprogramm einen anderen Benutzer auf der Datenbank verwendet als das eigentliche Programm. Dein Installationsprogramm braucht die Rechte um tabelllen anzulegen. Das Hauptprogramm in der Regln nur rechte um Tabellen zu lesen und zu schreiben.

Viele verwenden leider immer einfach den Root Benutzer einer DB. Das ist natürlich gerade bei Java grob fahrlässig, da ich die Zugangsdaten innerhalb von Sekunden aus dem Code herausgefunden habe und dann mit der Datenbank machen kann was ich will.

Als immer schön verschiedene Benutzer anlegen und verwenden.

Wenn du das machst kannst du übrigens auch gerne den Installer Code in dein Hauptprogramm integrieren. Nur sollltest du dann beim Aufruf dieser Methoden vorher einfach die Zugangsdaten über einen Dialog oder eine externe (nicht mit dem Programm mitgelieferte) Datei erfragen. Somit kann diese keiner bekommen und deine DB ist wieder geschützt.

Gruß

Claus

 

[Tobse]

die Zugangsdaten innerhalb von Sekunden aus dem Code herausgefunden

Wie du selbst schreibst, ist es eine absolute Todsünde, Zugangsdaten in den Code zu schreiben:

die Zugangsdaten über [...] eine externe (nicht mit dem Programm mitgelieferte) Datei erfragen

Wenn wir hier von einer Webanwendung Sprechen dann sollte die DB hauptsächlich von einer Firewall geschützt werden und die Zugangsdaten sollten NUR im Produktivsystem hinterlegt sein.

Bei einer Desktopanwendung ist das alles sowieso nur Augenwischerei weil die angreiffer Physikalischen Zugriff auf den Rechner und die Datenbank-Dateien haben.

 

[Thallius]

Wenn wir hier von einer Webanwendung Sprechen dann sollte die DB hauptsächlich von einer Firewall geschützt werden und die Zugangsdaten sollten NUR im Produktivsystem hinterlegt sein.

Bei einer Desktopanwendung ist das alles sowieso nur Augenwischerei weil die angreiffer Physikalischen Zugriff auf den Rechner und die Datenbank-Dateien haben.

Ich dachte jetzt eher an eine Desktopanwendung die auf eine Datenbank auf einem externen Server zugreift. Wobei man hier nach Möglichkeit natürlich besser mit einem Webservice arbeitet.

Gruß

Claus

 

[Meeresgott]

Die Anwendung mit der H2-Datenbank ist nicht wirklich eine Desktop-Anwendung. Es ist ein kleines Programm, dass Messdaten sammelt.

das ganze nutzt aber nur dann etwas, wenn dein installprogramm einen anderen Benutzer auf der Datenbank verwendet als das eigentliche Programm

Bei H2 ist es meines Wissens nicht möglich verschiedene User mit verschiedenen rechten Anzulegen.
Zumindest nicht in der im Code Integrierten Variante. Beim H2-Database Server ist wahrscheinlich sowas vorhanden. Ist für mich nur leider genauso unpraktisch wie der MySQL-Server.

ch dachte jetzt eher an eine Desktopanwendung die auf eine Datenbank auf einem externen Server zugreift. Wobei man hier nach Möglichkeit natürlich besser mit einem Webservice arbeitet.

Diese Funktion habe ich auch um die Messdaten einzusammeln. (Alle 24h Stunden überträgt mein Programm die Liste mit den Messdaten an einen Server).
Das Programm hat allerdings nicht direkten Zugang zu einer Datenbank sondern über einen Server der einen Technischen-User benutzt.

Der "User" meines Clients hat nur das Elementarrecht auf einer einzigen Tabelle was hinzufügen zu dürfen. Es ist also kein großes Problem wenn jemand an die Userdaten kommt. Da ein Algorithmus die Eingaben überwacht und wenn Nonsens rein geschrieben der User gesperrt wird.
Und ich bekomme dann eine Nachricht und muss mich dann selbst drum kümmern.

Es geht mir bei der Erstellung der H2-Datenbank nur um: "wie man es macht".
Auch wenn ich keine Verschiedenen User habe möchte ich es dennoch so Professionell wie möglich machen.

Und ich fand die Idee mit dem Installer sehr gut