Derby/JavaDB Probleme beim anlegen einer embedded DB

[SteeL1942]

Moin,

versuche seit ein paar Stunden, mich an Datenbanken und Java heran zu tasten. Dazu wollte ich mittels Derby eine embedded Datenbank erstellen. Um es vorweg zu nehmen: Von "guten Kentnissen" in sachen Datenbanken bin ich weit weg. Das Thema wurd in der schule zwar mal angeschnitten, aber das hat sich nur auf ein paar abfragen einer mysql datenbank beschränkt.
Daher wollte ich für den Anfang erstmal nur ein bisschen mit den Befehlen herum spielen, um der Sache etwas näher zu kommen. Aber da bin ich schon gleich vor die Wand gelaufen :autsch:

Mein Programm sieht im moment so aus:

import java.awt.Button;
import java.awt.Frame;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;

public class Start extends Frame{
	
	private Button los;
	private Connection con;
	public static void main(String[] args)
	{	
		new Start();
	}
	
	public Start()
	{
		this. setSize(500,500);
		this.setVisible(true);
		this.setLayout(null);
		los = new Button("los");
		los.setBounds(50,50,100,20);
		add(los);
		
        los.addActionListener(new ActionListener(){
            public void actionPerformed(ActionEvent e){
                aktion();
            }});
        
		try {
			Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
			con = DriverManager.getConnection( "jdbc:derby:testDB;create=true" );
		} catch (Exception e1)
		{
			System.out.println(e1.getMessage());
		}
	}
	
	private void aktion()
	{
		Statement test;
		ResultSet rs;
		try {
			test = con.createStatement();
			test.executeUpdate("CREATE TABLE PUNKTELISTE (NAME VARCHAR(50), Punkte INTEGER)");
			test.executeUpdate("INSERT INTO punkteliste (Name, Punkte) Values ('Hugo', 1234)");
			rs = test.executeQuery("SELECT * FROM PUNKTELISTE");
			System.out.println(rs.getString(1));
		} catch (SQLException e) {
			System.out.println(e.getMessage());
		}
		
	}

}

Einfach ein Fenster mit nem Button, der die Befehle dann zur DB sendet. Die Tabelle erstellen und einen Datensatz einfügen funktioniert ohne Probleme. Aber sobald er zu dem Select-Befehl kommt, spuckt er folgendes aus:

Invalid cursor state - no current row.

Bei der suche hier im Forum bin ich auf einen Beitrag gestoßen, wo jemand das selbe Problem hatte. Von seiner "Lösung" habe ich die drei Befehle 1:1 kopiert und trotzdem läuft es nicht.
Auch wenn ich Zeile 51 durch

rs = test.executeQuery("SHOW TABLES");

ersetze, zickt er rum. Da bekomme ich folgenden Fehler:

Syntax error: Encountered "SHOW" at line 1, column 1.

Bei letzterem meckert er ja wegen syntax, aber wie formuliere ich das richtig? Bei dem SQL-kram in der Schule hat es so funktioniert Ich hoffe mal, dass mir da jemand auf die Sprünge helfen kann

gruß SteeL

 

[Guybrush Threepwood]

Du musst den Cursor erst bewegen, also

rs.next();

Falls Du mehrere Ergebnisse durch das Select erwarest, dann irgend etwas à la

while (rs.next()){
    //do something
}

 

[nillehammer]

Ich weiß nicht, wie gnägidg Derby bei Groß-Klein-Schreibung ist, aber versuch mal, darauf zu achten. Das ist in Deinen Statements etwas wild. Ich schlage folgendes vor:
[JAVA=49]
test.executeUpdate("CREATE TABLE Punkteliste (name VARCHAR(50), punkte INTEGER)");
test.executeUpdate("INSERT INTO Punkteliste (name, punkte) VALUES ('Hugo', 1234)");
rs = test.executeQuery("SELECT * FROM PUNKTELISTE");
[/code]
Außerdem musst Du (am besten in einer Schleife) rs.next() aufrufen.
[EDIT]
Ach man, da war wieder einer schneller
[/EDIT]

 

[JimK]

Du solltest mal prüfen, ob in Derby der Befehl "SHOW TABLES" überhaupt existiert.

 

[SteeL1942]

Soo. Dank dem hinweis mit rs.next() zeigt er in der tat was an. Was das "SHOW TABLES" angeht, so war ich davon ausgegangen, dass er das kennt. Die anderen Befehle gabs bei dem mysql ja auch. aber nun ja, dann wohl nicht ^^
wie heißt denn der dazu passende befehl bei derby?

 

[JimK]

Moin

Ich arbeite auch gerade mit einer embedded Datenbank und musste feststellen, dass einige Befehle von abweichen.

Schau mal hier

 

[SteeL1942]

Thx. Jez kann ich erstmal weiter experimentieren

 

[SteeL1942]

Gibt es irgendeine möglichkeit den log bei derby auszuschalten? ich war jez soweit, dass ich per schleife ein paar hundert einträge in die datenbank speisen wollte. das hat doch ziemlich lange gedauert. ich vermute, es liegt am log. der erstellt ja in dem unterordner log immer irgendwelche logfiles während daten neu eingefügt werden. habe auch schon versucht mit diesem aufrum die datenbank in den ram zu legen:

DriverManager.getConnection( "jdbc:derby:memory:testDB;create=true;dataEncryption=true;bootPassword=xxxxx" );

das scheint er auch zu machen. nur wird es nicht wesentlich schneller. kann ich da was ändern??

 

[Guybrush Threepwood]

Wie lange hat es denn gedauert? Hast Du zwischen dem Startup und dem Einspeisen der Daten getrennt gemessen? Es gibt viele Gründe, die die Geschwindigkeit reduzieren können. Inserst bei Derby scheinen wohl generell nicht sooo schnell zu sein und es gibt einige Tuning-Tipps : java - Apache Derby INSERTS are slow - Stack Overflow
Ich arbeite mit H2 und da ist das INSERT eigentlich recht flott. Verwendest Du PreparedStatements? Das hat viele Vorteile. Neben der Sicherheit ist es die Geschwindigkeit bei der mehrfachen Verwendung.

P.S.: Aus dem "Tuning-Handbuch" von Derby ( http://db.apache.org/derby/docs/dev/tuning/tuningderby.pdf )

Avoid inserts in autocommit mode if possible
Inserts can be painfully slow in autocommit mode because each commit involves an update of the log on the disk for each INSERT statement. The commit will not return until a physical disk write is executed. To speed things up:

• Run in autocommit false mode, execute a number of inserts in one transaction, and then explicitly issue a commit.
• If your application allows an initial load into the table, you can use the import procedures to insert data into a table. Derby will not log the individual inserts when loading into an empty table using these interfaces. See the Derby Reference Manual and the Derby Server and Administration Guide for more information on the import procedures.

 

[SteeL1942]

Mit PreparedStatements geht deutlich schneller und wenn ich die Datenbank dann auch im RAM ablege, gehts in wenigen Sekunden. So stelle ich mir das vor

 

[SteeL1942]

Glaube, jetzt stehe ich vor einem Problem, dass sich so ohne weiteres nicht lösen lässt. Dank Datenbank im Ram und prepared statements hab ich ja schon ordentlich an Geschwindigkeit gewonnen, aber jetzt werde ich wieder ausgebremst:

Habe die Datenbank im Ram abgelegt und agiere nur über prepared statements. Frage ich nun ein Element aus der datenbank ab, so vergehen 3-4 sekunden, bis ich das ergebnis erhalte. An sich erstmal nicht tragisch. Wenn ich aber mehrere 100 Elemente abfragen will, vergehen so schnell mehrere minuten.
Habe die Datenbank mit 300.000 datensätzen gefüttert. Das dürfte wohl zu viel sein, oder? nützt es was, wenn ich die tabellen aufsplitte in mehrere kleine?
Ein blick in den Taskmanager zeigt das Problem: javaw.exe ist bei 25% CPU-auslastung, bei mir also genau einen Kern. Scheint also die CPU zu bremsen.
Bis jetzt hatte ich die daten immer in einer Hash-Table. Das war bedeutend schneller -.-

 

[Guybrush Threepwood]

Ich nehme an, es dass es mit der Indexierung zu tun hat. Die Datenbank sind sehr schnell, wenn Du auf Objekte über deren ID zurück greifst. Wenn Du andere Felder verwendest, dann geht es unter Umständen langsam, da die Datenbank komplett durchsucht werden muss. Es ist aber möglich, die Variablen indexieren zu lassen und das beschleunigt den Zugriff enorm.

 

[Guybrush Threepwood]

P.S.: Wenn Du ohnehin die Datenbank nur im Speicher hälst, worin liegt dann eigentlich der Vorteil der Verwendung eines Datenbanksystems? Vielleicht gäbe es ja Datenstrukturen, die Deinen Anwendungszweck besser erfüllen als Derby.

P.P.S. Probieren mal H2 aus. Funktioniert es damit besser als bei Derby?

P.P.P.S.: CREATE INDEX statement

 

[SteeL1942]

P.S.: Wenn Du ohnehin die Datenbank nur im Speicher hälst, worin liegt dann eigentlich der Vorteil der Verwendung eines Datenbanksystems? Vielleicht gäbe es ja Datenstrukturen, die Deinen Anwendungszweck besser erfüllen als Derby.

Bis jetzt habe ich mit Hashtables und Listen gearbeitet. Das hat mich aber nicht so überzeugt. Hatte also für einen Datensatz ein eigenes Objekt erstellt, was dann in der Liste bzw Hashtable abgelegt wurde. Problem dabei ist halt nur, dass ich bei der Liste nach einem Kriterium sortieren muss und bei der Hashtable das Objekt ja mit einem parameter abgespeichert wird. Nur kann eben der Parameter, den ich zur Suche angebe, variieren. Ich kann zwar für jeden parameter ne extra Hashtable anlegen, aber bin mir nicht so sicher, ob das so zu "guten Stil" passt. Deswegen erschien mir eine Datenbank sinnvoller.

Mit dem Index werd ichs mal versuchen



EDIT: Mit dem Index hab ich jetzt 1000 Ergebnisse in 5 Sekunden. Das sieht doch gleich deutlich besser aus