Geeignetes DB-System

[p3lotud0]

Hallo,

bin jetzt schon einige Tage dabei ein geeignetes DB-System für mich zu finden.
Folgende Dinge sind dabei zu beachten:

1.) Das Programm, welches auf die DB zugreift, soll auch über Netzwerk funktionieren, Sprich: ein Programm als Server mit der DB und die anderen Programme halt als Clients, die auf die DB über Netzwerk zugreifen.

Das bietet sich ja fast alles an (MySQL, Derby, etc.), ABER:

2.) Wenn ich das Programm hinterher "ausliefern" würde, fände ich das ein bißchen zu viel verlangt von z.B. einem nicht so bewandten Benutzer zuerst eine MySQL aufzusetzen etc., so dass ich schon gerne was embeddeded haben möchte.
Was einfach mitgeliefert wird und einfach - wenn überhaupt - zu installieren ist.

Was könnt Ihr mir da empfehlen. Würde ja direkt sagen JavaDB, also Derby, aber wie sieht das mit der Serverrolle aus?

Vielen Dank schon mal im Voraus.

Saludos,

p3lotud0

 

[DocJunioR]

Wenn du ODBC nutzt, könntest du theoretisch einfache csv-Dateien als Datenbank nutzen.

Weiß aber nicht, ob der Windows-ODBC auch von außen erreichbar ist..

 

[p3lotud0]

So weit ich weiss, ist ne ODBC über Netzwerk zu erreichen.
Sollte man dann lieber darauf zurückgreifen? Vielleicht mit ner mdb arbeiten dann? Denke mal, dass das zum Einrichten am wenigsten umständlich wäre oder wie sehr Ihr das?
Aber: Was wird dann vom Endbenutzer verlangt? Dass er Access installiert hat oder reicht die Möglchkeit zur ODBC-Einrichtung? Denn Access als Voraussetzung kann es ja nicht sein.

Saludos,

p3lotud0

 

[robertpic71]

So weit ich weiss, ist ne ODBC über Netzwerk zu erreichen.

Die Datenbank, welche im ODBC-Treiber konfiguriert ist, kann über das Netzwerk erreichen. Bei Access steht dann "C:\PfadXY\accessXY.mdb" drinnen. D. h. für Netzwerkbetrieb müsste das File als Netzwerklaufwerk zur Verfügung stehen. Bei CSV-Dateien wird kein Mehrbenutzerbetrieb möglich sein.

DAHER:
Du warst schon auch dem richtigen Dampfer mit Derby (oder HSQL oder H2...). Diese embedded Datenbanken lassen sich auch im Client-Server-Modus starten. Das ist genau das was du brauchst.

Ich habe mit Derby nicht viel am Hut (ich bevorzuge H2), auf die Schnelle habe >> das hier << gefunden.

 

[p3lotud0]

Hi,

als reine embedded hätte ich auch keine Probleme, da man so nur die entsprechende JAR hinzufügen muss. Aber wenn ich wieder bei Server/Client bin, reicht das ja nicht mehr aus, oder?
Das heisst ich müsste bei jeder Installation erst das Start- und Stopskript anpassen. Zwar nicht die Welt und mit etwas Aufwand auch zu automatisieren, aber mhmmm... Irgendwie gefällt mir das noch nicht

Aber ne einfache Installation für Noobs bei ner DB-Server-Geschichte wird wohl überall Probleme machen...

 

[robertpic71]

Die Datenbank in einer eignen JVM laufen zu lassen ist nur eine Lösung. Sicher kann man bei Derby den Server auch aus der Applikation starten.

Bei meiner verwendeten H2 (auch eine embedded DB, siehe http://www.h2database.com/) sieht das ungefähr so aus:

import org.h2.tools.Server;
...
// TCP Server starten, Parameter vorbereiten
String[] args = new String[]{"-ssl", "true"};
Server server = Server.startTcpServer(args);
...
// stop the TCP Server
server.stop();

So was in der Art müsste es bei Derby auch geben....Die Clients machen dann eine normale JDBC-Verbindung. Ein Vorteil von H2 ist noch, dass immer nur ein Jar (und immer das gleich Jar) für Server und Client verwendet wird.

 

[p3lotud0]

Vielen Dank. Habe mir die H2 installiert und werde wohl bei dieser bleiben. Das erfüllt so ziemlich genau das, was ich mir vorgestellt habe

Saludos,

p3lotud0

 

[Milbo]

Die Datenbank in einer eignen JVM laufen zu lassen ist nur eine Lösung. Sicher kann man bei Derby den Server auch aus der Applikation starten.

Bei meiner verwendeten H2 (auch eine embedded DB, siehe http://www.h2database.com/) sieht das ungefähr so aus:

import org.h2.tools.Server;
...
// TCP Server starten, Parameter vorbereiten
String[] args = new String[]{"-ssl", "true"};
Server server = Server.startTcpServer(args);
...
// stop the TCP Server
server.stop();

So was in der Art müsste es bei Derby auch geben....Die Clients machen dann eine normale JDBC-Verbindung. Ein Vorteil von H2 ist noch, dass immer nur ein Jar (und immer das gleich Jar) für Server und Client verwendet wird.

Verstehe ich das richtig, dass die H2 auch gleichzeitig verschlüsselte Verbindung unterstützt?

Also muss ich nur noch meinen Client das verschlüsseln beibringen,.. oder wie?

Irgendwie bringt mich das alles etwas durcheinander.

Ich brauche eine verschlüsselte Client/Server Verbindung. Server würde ich aufsetzen (lassen). Geht um ein Kopierschutzsystem übers Inet.
Ist H2 auch dafür geeignet?

Vielen Dank im vorraus...

da Milbo

 

[robertpic71]

Soweit ich das durchblicke, unterstützt H2 verchlüsselter Verbindungen zwischen dem H2 Datenbankserver und dem Client (= h2 JDBC-Treiber).

Also für eine sichere Verbindung zwischen H2-Datenbank und H2-Client müsstest du nur den Server und die Client-Connectionssetting entsprechend konfigurieren.

Wenn du den Server von deiner Applikation laufen läßt, könnte die Serverapplikation direkt (embedded) auf die Datenbank zugreifen.

Um Missverständnissen vorzubeugen:
- das Ganze nutzt dir nur etwas wenn du H2 auch als Serverdatenbank benutzt
- wäre es wahrscheinlich besser, einen Webservice vorzuschalten, um gewissen Problemen aus dem Weg zu gehen (durch Firewalls verschlossene Ports, Proxysserver)

Hier noch aus der H2-Doku:

SSL/TLS Connections
Remote SSL/TLS connections are supported using the Java Secure Socket Extension (SSLServerSocket / SSLSocket). By default, anonymous SSL
is enabled. The default cipher suite is SSL_DH_anon_WITH_RC4_128_MD5 .

Wie weit das für dich ausreichend wäre, kann ich nicht beurteilen. Wenn es in Sachen Verschlüsselung mit H2 ins "Eingemachte" geht, empfiehlt es sich wahrscheinlich im H2 Forum nachzufragen.


/Robert