# Sqlite API für JAVA ?



## Plenske (27. Feb 2008)

Hallo,

Ich habe eine Desktop anwendung mit Daten die ich in einer mysql datei speichern möchte. Einen MySql server benötige ich ja in dem Fall nicht. Das ganze soll auch recht fix geh sprich ich habe an sqlite gedacht: 

http://www.zentus.com/sqlitejdbc/

Was haltet Ihr von obiger API taugt die was bzw. hat damit jemand Erfahrungen gesammelt oder kennt jemand sonst gute sqlite APIs für JAVA ?


----------



## J.C. (28. Feb 2008)

Möchtest du SQL Querys in eine Datei (.sql) schreiben oder Daten in eine Datenbank schicken. SQLiteJDBC ist ein Datenbanktreiber den du brauchst um auf eine SQL Datenbank zu zugreifen.

MfG


----------



## Plenske (28. Feb 2008)

J.C. hat gesagt.:
			
		

> Möchtest du SQL Querys in eine Datei (.sql) schreiben oder Daten in eine Datenbank schicken. SQLiteJDBC ist ein Datenbanktreiber den du brauchst um auf eine SQL Datenbank zu zugreifen.
> 
> MfG



Ich benötige Sqlite aber keine Datenbank. Doch soweit ich weiß kann ich mit Sqlite auch query abfrage machen über daten die in einer Datei sind (soll sogar schneller sein).


----------



## tuxedo (28. Feb 2008)

Schau doch auch mal nach "HSQLDB", "H2", ... (google hilft) Da hast du wenigstens natives Java ..

- Alex


----------



## Plenske (28. Feb 2008)

naja das hier bietet auch natives Java: --> http://www.zentus.com/sqlitejdbc/

also würdet ihr mir obigen link empfehlen, wenn ich auf platformunabhängigkeit wert legen würde?


----------



## tuxedo (29. Feb 2008)

Der Treiber ist 100% Java, die DB "SQLite" ist das AFAIK nicht. 

Empfehle für StandAnlone Anwendungen bzw. Datenbanken "H2".

- Alex


----------



## Plenske (29. Feb 2008)

alex0801 hat gesagt.:
			
		

> Der Treiber ist 100% Java, die DB "SQLite" ist das AFAIK nicht.
> 
> Empfehle für StandAnlone Anwendungen bzw. Datenbanken "H2".
> 
> - Alex


 danke aber da steht doch:


> A JDBC driver for SQLite. It comes in two flavours, a 100% Pure Java driver based on NestedVM or a native JNI library. The pure java driver is compatible, you can follow the Java dream and use it anywhere with no worries.



sprich der treiber auf der site ist DOCH 100 % JAVA ?


----------



## tuxedo (29. Feb 2008)

Hab ich je was anderes behauptet?

ich zitiere ich mal selbst:

>> Der Treiber ist 100% Java, die DB "SQLite" ist das AFAIK nicht. 

Ich plädiere jedoch für eine Java-DB + Java-Treiber.

H2 gehört da dazu. SQLite ist eine nicht-Java Datenbank welche mit einem Java-Treiber der JNI und andere Techniken verwendet in Java benutzt werden kann.

JNI-Calls sind nicht immer die schnellsten. Dann doch lieber alles in Java machen. 

Ist meine Meinung. Wenn du unbedingt SQLite benutzen willst hindert dich keiner dran. 

- Alex


----------



## Plenske (29. Feb 2008)

alex0801 hat gesagt.:
			
		

> Hab ich je was anderes behauptet?
> 
> ich zitiere ich mal selbst:
> 
> ...



achso ich dachte JNI calls mit C würde das ganze beschleunigen und sei daher schneller als alles in java... danke dir Alex!


----------



## tuxedo (29. Feb 2008)

Die Codeausführung in C ist schnell. Ja. Aber irgendwie müssen die Daten von C nach Java. Und gewisse Datenmengen von C nach Java über JNI schaufeln hat etliche interne Aufrufe an die JVM zur Folge. Und diese Aufrufe bremsen.

Wenn du ein Berechnung in C machen willst und Java mittels JNI die Parameter zur Rechenruntine runterreicht, dann ist das recht schnell. Das was in Java lange dauern würde, kannst du in C schnell rechnen. Die Dauer, die das übermitteln des Ergebnis von C nach Java braucht fällt da nicht ins Gewicht.

Aber wenn du viele Daten häugig hin und herschiebst, ist der Vorteil des schnellen C-Teils wieder weg.

Hab im Praxissemester einen Treiber-Wrapper geschrieben. Der Treiber war für eine CAN-Karte welche mit dem CAN-Bus im Automobilbereich kommunizieren konnte. Da gehen im Worst-Case Megabyteweise Daten hin und her. Lässt sich mit einer Netzwerkverbindung vergleichen.

So. der Treiber war in C, die Anwendung in Java. Das ansteuern des Treibers hab ich mittels JNI gemacht. Das Senden und Empfangen der Daten ging mit einer lokalen Socketverbindung über localhost BEDEUTEND schneller als wenn ich diese via JNI kommuniziert hätte (localhost wird glaube ich, je nach Betriebssystem, direkt über den RAM-Speicher gemapped...)

- Alex


----------

