Java DB Zugriff auf Access (Migration auf andere DB)

[JavaManiac]

Hallo,

ich stehe zurzeit vor folgender Problematik:

ich habe eine Access-Datenbank mit Forms die den Datenzugriff handeln.
Die Anwendung läuft schon produktiv und dahinter steht ein sauberes Datenbankmodell.

Da ich aber nun weg will von dem Micro$oft Access Gemüse, und die Sache mit Java umsetzen will, die Frage an euch.
Soll ich auf eine andere Datenbank migrieren? Wenn ja welche?

Und hat das schon mal jemand (außer in der Theorie SQL-Export-File --> SQL Import) gemacht?

Kann mir dann noch jemand Tipss für den Datenbank Zugriff geben (über JDBC?)

Viele Dank

Gruß
JavaManiac

 

[Gast]

Vieleciht reicht dir DBUnit für den Export und Import der Daten.

 

[JavaManiac]

Also, wie gesagt ich hänge nicht an M$ Access.

Welche Datenbank würdet ihr mir empfehlen? (max. 3 PC's die darauf zugreifen)
Keine Hohen Performance Ansprüche.

Gruß
JavaManiac

 

[Gast]

> Keine Hohen Performance Ansprüche.

Alles ist schneller als Access, möglich wäre also alles von HSQL, MySQL (aber nur mit InnoDB tabellen, ISAM taugt nicht für RDBMS), PostgreSQL, Derby, etc. pp.

JDBC ist out, iBatis oder JPA.

 

[Gelöschtes Mitglied 5909]

verwende h2 oder hsql zusammen mit jpa/hibernate

 

[maki]

Solange H2 kein rowlocking untertützt, kann ich davon nur abraten.

 

[bronks]

... Welche Datenbank würdet ihr mir empfehlen? (max. 3 PC's die darauf zugreifen)
Keine Hohen Performance Ansprüche ...

MS SQL-Server Express. Da kannste Deine DB einfach von Access aus hochladen. Sollte es den Daten dort nicht gefallen, dann kannst Du die DB mit dem Migrationstool von MsSql ganz unproblematisch nach MySql holen.

 

[Gast]

Solange H2 kein rowlocking untertützt, kann ich davon nur abraten.

Hast du etwas gegen H2? :?

Warum sonst pickst du dir H2 (neben der HSQL angeführt) heraus, obwohl:
1.) HSQL kein Row Level Locking unterstützt
2.) H2 schon bald ein Jahr das Feature "Multi Version Concurrency" als Beta im Progamm hatte
3.) Seit knapp 2 Monaten auch das Row Level Locking (innerhalb der MVC - nicht mehr Beta) anbietet

Nicht zu vergessen, der Threadsteller kommt von MS Access. Dort ist das Feature 1. erst ab neueren Verisonen und 2. per Default abgeschaltet (und 3. unzuverlässig, aber das ist mein subjektive Erfahrung).

Weiters braucht es schon bestimme Konstellationen, damit sich das fehlenden/abgeschaltetes Rowlevel-Locking irgendwie negativ auswirkt. Dabei darf man auch nicht vergessen, dass embedded Datenbanken sowieso keine Multithread-Core haben.

Das Feature fehlt (HSQL) bzw. fehlte (H2) ja ohnehin nicht ohne Grund. Standard ist mittlerweile das "optmistic locking". Da braucht es keine gehaltene Satzsperren. Ich seh da kein Probleme ein Projekt mit HSQL/H2 (auch mit Hibernat) abzuwicklen - wie es sie auch einige davon gibt.

Alles ist schneller als Access

Mir liegt es fern, M$ Access zu verteidigen. Aber es gibt bestimmte Fälle, wo Access schnell ist. Vor allem wenn die Datenbank auf der lokalen Festplatte liegt. Die Liste der Nachteile ist aber sicher länger und vorallem Access am Netzwerklaufwerk sollte man überdenken.

Die Idee mit dem MS SQL Server Express von bronks ist gut. Irgendwie haben die Datenbanktools, welche ich kenne, alle Probleme damit, Metadaten aus Access zu bekommen. Hat man einmal die Datenbank extrahiert kann man sie überall hin "schupfen".

 

[Gast]

Hast du etwas gegen H2? icon_confused.gif

Warum sonst pickst du dir H2 (neben der HSQL angeführt) heraus, obwohl:
1.) HSQL kein Row Level Locking unterstützt
2.) H2 schon bald ein Jahr das Feature "Multi Version Concurrency" als Beta im Progamm hatte
3.) Seit knapp 2 Monaten auch das Row Level Locking (innerhalb der MVC - nicht mehr Beta) anbietet

Achso, dann rate ich von HSQL auch ab, wenn das auch kein Rowlocking unterstützt

Optimistic Locking halte ich auf DB Level für Suboptimal, gibt genug Anwendungsfälle in denen man es eben pessemistisch will.

Propritäre Lösungen ("Multi Version Concurrency") sind bestimmt ganz toll wenn sie sich etablieren, würde sie persönlich nicht einsetzen, gibt doch genug DBs auf dem freien Markt, wieso wegen eines Features auf eine angewiesen sein?

Gehe einfach mal davon aus, dass der TS keine Embedded sondern eine Server Variante nutzen will, hat ja auch nirgendwo etwas anderes behauptet, und embedded ist imho immer noch eine Ausnahme für ein RDBMS.

Trotzdem gut zu Wissen das H2 nun auch row level locking unterstützt, hab nie verstanden warum man nicht erst dem Standard (SQL 99?) unterstützen will bevor man sich an Eigenentwicklungen macht.