mardi 24 mars 2015
MySQL Asynchroner MySQL Zugriff - Sinnvoll ?
Posted on 06:43 by verona
Hallo liebe Community,
ich bin seit einiger Zeit auf der Suche nach einer Lösung, wie ich meine Datenbankverbindung möglichst effizient, benutzerfreundlich und vorallem performant arbeiten lassen kann. Dabei gibt es einen Haufen Probleme, von denen ich viele kleine lösen konnte, jedoch fehlt es noch an wesentlichen Stellen.
Ich habe mir bisher schon eine kleinen Libary zurechtgelegt, die es ermöglichen soll, dass ich möglichst benutzerfreundlich Querys durchführen kann.
Mein System besteht derzeit aus folgenden Klassen
Im Wesentlichen ist DatabaseOperation mit PreparedStatement und Result mit ResultSet zu vergleichen. Sie helfen mir lediglich durch eine im Endeffekt kürzere und übersichtlichere Syntax.
Query ist ein enum, in dem alle meine Query Strings drinstehen. Sobald man einen aus dem Enum 'herausholt' wird daraus ein PreparedStatment, das als DatabaseOperation weiterverarbeitet wird. Wird nun ein Query ausgeführt, wird ein Result zurückgegeben. Dies erspart hässliche Try-catchblöcke im "Hauptcode" und ist sehr variabel.
Nun zu meinem eigentlichen Hauptproblem. Ich habe nach vielem Suchen bei StackOverFlow und weiteren (Java-)Plattformen entschlossen, bzw. herausgelesen, dass es besser ist, den MySQL Zugriff asynchron zu gestalten.
Ein Update Asynchron laufen zu lassen, ist kein Problem, aber eine Abfrage laufen zu lassen meiner Meinung nach schon. Ich glaube, ich habe da etwas missverstanden, aber dadurch, dass man einen Query asynchron laufen lässt, ist er doch nicht schneller und man hat die Ergebnisse trotzdem erst später ?
Ich muss, wenn ich einen Query durchführe zwingend warten, bis dieser auch sein ResultSet zurückliefert (NullPointerException lässt grüßen), bis ihr mit der Datenverarbeitung weitermachen kann.
Wo also soll man den Query asynchron laufen lassen ?
Bringt es überhaupt etwas ?
Viel Danke ;)
- Sasuke
ich bin seit einiger Zeit auf der Suche nach einer Lösung, wie ich meine Datenbankverbindung möglichst effizient, benutzerfreundlich und vorallem performant arbeiten lassen kann. Dabei gibt es einen Haufen Probleme, von denen ich viele kleine lösen konnte, jedoch fehlt es noch an wesentlichen Stellen.
Ich habe mir bisher schon eine kleinen Libary zurechtgelegt, die es ermöglichen soll, dass ich möglichst benutzerfreundlich Querys durchführen kann.
Mein System besteht derzeit aus folgenden Klassen
- Database.class (http://ift.tt/1OvHBV4)
- DatabaseOperation.class (http://ift.tt/1y0OyTq)
- Result.class (http://ift.tt/1OvHAQT)
- Query.class (http://ift.tt/1y0OyTq)
Im Wesentlichen ist DatabaseOperation mit PreparedStatement und Result mit ResultSet zu vergleichen. Sie helfen mir lediglich durch eine im Endeffekt kürzere und übersichtlichere Syntax.
Query ist ein enum, in dem alle meine Query Strings drinstehen. Sobald man einen aus dem Enum 'herausholt' wird daraus ein PreparedStatment, das als DatabaseOperation weiterverarbeitet wird. Wird nun ein Query ausgeführt, wird ein Result zurückgegeben. Dies erspart hässliche Try-catchblöcke im "Hauptcode" und ist sehr variabel.
Nun zu meinem eigentlichen Hauptproblem. Ich habe nach vielem Suchen bei StackOverFlow und weiteren (Java-)Plattformen entschlossen, bzw. herausgelesen, dass es besser ist, den MySQL Zugriff asynchron zu gestalten.
Ein Update Asynchron laufen zu lassen, ist kein Problem, aber eine Abfrage laufen zu lassen meiner Meinung nach schon. Ich glaube, ich habe da etwas missverstanden, aber dadurch, dass man einen Query asynchron laufen lässt, ist er doch nicht schneller und man hat die Ergebnisse trotzdem erst später ?
Ich muss, wenn ich einen Query durchführe zwingend warten, bis dieser auch sein ResultSet zurückliefert (NullPointerException lässt grüßen), bis ihr mit der Datenverarbeitung weitermachen kann.
Wo also soll man den Query asynchron laufen lassen ?
Bringt es überhaupt etwas ?
Viel Danke ;)
- Sasuke
MySQL Asynchroner MySQL Zugriff - Sinnvoll ?
Categories: MySQL Asynchroner MySQL Zugriff - Sinnvoll ?
Inscription à :
Publier les commentaires (Atom)
0 commentaires:
Enregistrer un commentaire