Mysql und JDBC Grundsätze
Moin moin alle zusammen, ich programmiere gerade einen Webshop in Java mit GUI für den Desktop (Artikelpflege, Administration, multiuserfähig, Einbindung in Confixx, XML Schnittstelle, Open-Source natürlich). Meine Frage ist nun, ob es besser ist Rechenoperationen der Mysql DB zu überlassen oder besser dem Java Programm. Mir ist das nicht ganz klar ;( In der Doku von Mysql wird häufig in dem Statement der Wert berechnet bevor der Wert in eine Tabelle geschrieben wird, scheint also oft benutzt zu werden. Auf meiner ehemaligen Arbeit meinte aber der Projektleiter, das wäre "verschenkte Rechenzeit". IMHO stimmt das so nicht. Was sagen Eure Erfahrungen, was ist effizienter, modern? Grüsse Andre
Hi
Moin moin alle zusammen,
ich programmiere gerade einen Webshop in Java mit GUI für den Desktop (Artikelpflege, Administration, multiuserfähig, Einbindung in Confixx, XML Schnittstelle, Open-Source natürlich).
Meine Frage ist nun, ob es besser ist Rechenoperationen der Mysql DB zu überlassen oder besser dem Java Programm.
Mir ist das nicht ganz klar ;(
In der Doku von Mysql wird häufig in dem Statement der Wert berechnet bevor der Wert in eine Tabelle geschrieben wird, scheint also oft benutzt zu werden. Auf meiner ehemaligen Arbeit meinte aber der Projektleiter, das wäre "verschenkte Rechenzeit".
IMHO stimmt das so nicht.
Was sagen Eure Erfahrungen, was ist effizienter, modern?
Ich denke, es ist in Java schneller (weil es im Statement erst geparst werden muss), aber bei einem Webshop halte ich den Performance- Unterschied fuer Vernaechlaessigbar. Ein Punkt spricht allerdings fuer MySQL: Die verwendeten Werte sind garantiert aktuell. Hingegen koennen die, die dein Programm verwendet, von denen in der Datenbank abweichen, weil die sich gerade eben veraendert haben. Also wenn es z.B. um einen Lagerbestand geht, wuerde ich auf jeden Fall die Reduzierung in der Datenbank machen, weil dann auch garantiert der wirkliche Bestand reduziert wird und nicht der, den Dein Programm vor 100ms bekommen hat. Bye -- 1 Bodo Kaelberer 123 http://www.webkind.de/ 3 4 Politik ist, wenn viele sich streiten und keiner sich freut.
Am Dienstag, 16. März 2004 18:06 schrieb Bodo Kaelberer: [...]
Was sagen Eure Erfahrungen, was ist effizienter, modern?
Ich denke, es ist in Java schneller (weil es im Statement erst geparst werden muss), aber bei einem Webshop halte ich den Performance- Unterschied fuer Vernaechlaessigbar.
An das parsen des Statement habe ich nicht gedacht, das muss ich bestimmt aufpassen. Jedenfalls wenn die Statements gross werden.
Ein Punkt spricht allerdings fuer MySQL: Die verwendeten Werte sind garantiert aktuell. Hingegen koennen die, die dein Programm verwendet, von denen in der Datenbank abweichen, weil die sich gerade eben veraendert haben.
Das ist ein guter Grund, der für Mysql spricht. George hat angesprochen, das das ganze nicht in allen DB's gleich ist. PostGre, Max DB möchte ich vielleicht noch einschliessen. Mal sehen wie hoch der Aufwand dazu ist.
Also wenn es z.B. um einen Lagerbestand geht, wuerde ich auf jeden Fall die Reduzierung in der Datenbank machen, weil dann auch garantiert der wirkliche Bestand reduziert wird und nicht der, den Dein Programm vor 100ms bekommen hat.
Wegen dem GUI wollte ich die Last eigentlich auf den Server legen und dachte da an die Fähigkeiten von MySQL. Die Entscheidung fällt bislang definitiv auf Rechenoperationen in MySQL (Postgre & Co. klappt vielleicht auch..) Viele Grüsse Andre
Hi Andre,
Ich werde mich erst entschuldigen weil mein Deutsch
nicht sehr gut ist. Naechst werde ich fersuchen deine
frage zu beantworten un ein bischen mehr information
zu einbitten:
Wo du dein Rechenoperationen machen wirst is it eine
frage auf wie wilst du dein system weiter entwickeln.
Ich meine wenn du wilst daS dein system ein anderen DB
verwenden konte dan wirds du dein DB access/processing
code in dein Java program einhalten.
Wenn du sicher bist daS dein system immer MySQL
verwenden werde dann vielliecht kann es schneller
gehen wenn du dein Rechenoperationen im MySQL machst.
Ich hoffe daS hilft dir.
Danke.
George
--- Andre Heine
Moin moin alle zusammen,
ich programmiere gerade einen Webshop in Java mit GUI f�r den Desktop (Artikelpflege, Administration, multiuserf�hig, Einbindung in Confixx, XML Schnittstelle, Open-Source nat�rlich).
Meine Frage ist nun, ob es besser ist Rechenoperationen der Mysql DB zu �berlassen oder besser dem Java Programm.
Mir ist das nicht ganz klar ;(
In der Doku von Mysql wird h�ufig in dem Statement der Wert berechnet bevor der Wert in eine Tabelle geschrieben wird, scheint also oft benutzt zu werden. Auf meiner ehemaligen Arbeit meinte aber der Projektleiter, das w�re "verschenkte Rechenzeit".
IMHO stimmt das so nicht.
Was sagen Eure Erfahrungen, was ist effizienter, modern?
Gr�sse
Andre
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verf�gbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
__________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
Am Dienstag, 16. März 2004 18:40 schrieb George Stoianov:
Ich werde mich erst entschuldigen weil mein Deutsch nicht sehr gut ist. Naechst werde ich fersuchen deine
Kein Problem, mein Deutsch ist auch nicht das beste :)
Wo du dein Rechenoperationen machen wirst is it eine frage auf wie wilst du dein system weiter entwickeln. Ich meine wenn du wilst daS dein system ein anderen DB verwenden konte dan wirds du dein DB access/processing code in dein Java program einhalten.
Hmm, ich denke das eventuell noch postgreSQL und MAX DB zum Einsatz kommen könnte. Da möchte ich mich zwar noch nicht festlegen, aber zu andren DB's möchte ich schon ein wenig kompatibel sein.
Wenn du sicher bist daS dein system immer MySQL verwenden werde dann vielliecht kann es schneller gehen wenn du dein Rechenoperationen im MySQL machst.
Das GUI soll "multiuser fähig" werden, nun denken ich das es ein kleiner Performanzgewinn sein könnte, wenn der Client keine Rechenoperationen mehr machen muss. Vielleicht sind die Statements in PostGres und MAX DB ähnlich. Muss ich mal testen... Schön wäre es jedenfalls, wenn ich auf mehrere DB's setzen könnte. Ciao Andre
Hallo zusammen, wenn man das ganze mal rein architekonisch betrachtet, ist das weder eine Aufgabe für die GUI, noch eine Aufgabe für das DBMS, sondern für die Businesslogik (schön Neudeutsch gesagt ;-)) Also die klassische 3-Tier-Architektur. Weiterhin philosophiert (tut mir leid das ich das so hart ausdrücke) ihr darüber, auf welcher Seite die Berechnung schneller wäre. Aber es wurde nie darüber gesprochen, welche Art von Berechnungen - ausgehend von einem Webshop, würde ich sagen es handelt sich um einfache Additionen oder Subtraktionen - also nicht wirklich teure Berechnungen! Also langer Rede kurzer Sinn: Lass die GUI, GUI sein - ein Interface zwischen Benutzer und System, lege eine Schicht mit der Geschäftslogik dazwischen und laß die Datenbank machen, was ihre Aufgabe ist Daten verwalten! Dann hast Du zusätzlich auch eine Abstraktionsebene und kannst genau das machen, was Georg angesprochen hat, die Datenbank austauschen! So das waren meine bescheidenen 2Cent zum Thema HTH Lars
Abend
Das GUI soll "multiuser fähig" werden, nun denken ich das es ein kleiner Performanzgewinn sein könnte, wenn der Client keine Rechenoperationen mehr machen muss.
Reden wir hier von 1 bis 5 Users oder von 1000? (-; Mal nebenbei: Ich habe mit JDBC nie etwas gemacht. Allgemein hat man bei einfachen Client-Server Implementierungen (z.B. Browser <-> PHP) immer das Problem, daß man keiner Information, die vom Browser kommt, trauen kann. Was bietet JDBC an Sicherheitsmechanismen für die Übertragung, z.B. gegen manipulierte Statements? Oder in anderen Worten: Wer verhindert, dass ein manipulierter Client ein "DROP TABLE kundendaten" schickt? Und wie funktioniert die Anmeldung? Die Zugangsdaten werden ja wohl kaum im Applet stehen. Oder doch? Bye -- 1 Bodo Kaelberer 123 http://www.webkind.de/ 3 4 Politik ist, wenn viele sich streiten und keiner sich freut.
Am Dienstag, 16. März 2004 21:39 schrieb Bodo Kaelberer:
Das GUI soll "multiuser fähig" werden, nun denken ich das es ein kleiner Performanzgewinn sein könnte, wenn der Client keine Rechenoperationen mehr machen muss.
Reden wir hier von 1 bis 5 Users oder von 1000? (-;
Ich denke so bis 50 ist realistisch?? Habe ich mir ehrlich gesagt noch nicht genau überlegt! Je mehr je besser :) Was ist den bei vielen Usern besser, die Last auf den Server oder im Client? IMHO der Server.
Mal nebenbei: Ich habe mit JDBC nie etwas gemacht. Allgemein hat man bei einfachen Client-Server Implementierungen (z.B. Browser <-> PHP) immer das Problem, daß man keiner Information, die vom Browser kommt, trauen kann.
Joo, das kenne ich von Perl ;)
Was bietet JDBC an Sicherheitsmechanismen für die Übertragung, z.B. gegen manipulierte Statements? Oder in anderen Worten: Wer verhindert, dass ein manipulierter Client ein "DROP TABLE kundendaten" schickt?
Gute Frage, per default wird alles in Klartext sein... (???)
Und wie funktioniert die Anmeldung? Die Zugangsdaten werden ja wohl kaum im Applet stehen. Oder doch?
Es wird kein Applet geben. Auf dem Internetserver wird nur Apache mit mod_jk/tomcat laufen. Mysql natülich auch. Nur der Shop direkt ist manipulierbar, z.B. in den jemand versucht die Servlets zu steuern. Der Shop Besucher erwartet so oder so eine verschlüsselte Verbindung bei der Eingabe seiner Daten. Da kommt man ohne https nicht rum. Das UI muss ich mit Swing machen (leider gibt's QT nur als eval für M$) und ist zum Artikel rein hacken in eine "lokale DB" gedacht. Der Abgleich mit der DB auf dem I-Server wollte ich mittels SSH und XML lösen, vielleicht auch mit sql.txt. Das würde mit putty bzw pscp auf M$ ganz gut klappen. Mit Java gibt es allerdings auch eine API, womit man RSA & Co. benutzen kann. Ich bin wiedermal für alle Vorschläge und Hints zu haben, ist noch alles in der Planung. Ciao Andre
Andre Heine schrieb:
Und wie funktioniert die Anmeldung? Die Zugangsdaten werden ja wohl kaum im Applet stehen. Oder doch?
Es wird kein Applet geben. Auf dem Internetserver wird nur Apache mit mod_jk/tomcat laufen. Mysql natülich auch. Nur der Shop direkt ist manipulierbar, z.B. in den jemand versucht die Servlets zu steuern.
Ich versteh dann nur nicht, wie du überhaupt ein GUI implementieren willst. Das GUI läuft immer am Client und nicht am Server. Wenns im Browser laufen soll geht am Applet kein Weg vorbei, ansonsten ist es ne Java Client Anwendung, die ohne Browser arbeitet (zb Java Webstart) Mit Java am Server implementiert man aber kein GUI sondern generiert HTML welches wieder am Client angezeigt wird. Oder hab ich da was ganz falsch verstanden ? Gruss Michael
Am Mittwoch, 17. März 2004 10:39 schrieb Michael Rauter: [...]
Es wird kein Applet geben. Auf dem Internetserver wird nur Ich versteh dann nur nicht, wie du überhaupt ein GUI implementieren willst. Das GUI läuft immer am Client und nicht am Server. Wenns im Browser laufen soll geht am Applet kein Weg vorbei, ansonsten ist es ne Java Client Anwendung, die ohne Browser arbeitet (zb Java Webstart) Mit Java am Server implementiert man aber kein GUI sondern generiert HTML welches wieder am Client angezeigt wird. Oder hab ich da was ganz falsch verstanden ?
Der Shop wird mit Servlets (Tomcat) umgesetzt, da brauchst Du jedenfalls kein Applet. Alle Eingaben von Shop-Besuchern werden mit HTML Formularen (generiert von Servlets) und https abgefragt. Konfigurationen des Shop laufen nicht direkt über einen Browser, sondern aus dem GUI. Für die Aktualisierung der Internet-DB werden die benötigten Informationen auf anderen Wege Transportiert. (generic Servlets <-> XML, Verschlüsselung SSH/Putty oder Java Krypto API) So etwas ähnliches habe ich schon mit SAP BAPI's gemacht, aber ohne Verschlüsselung (Kein WWW beteiligt). Serverseitig wahr das ganze recht schnell und stabil! Das sind so meine vorgedachten Planungen... CIao Andre
Hallo Ich weiss nicht, wieso diese Liste so konfiguriert ist, dass man standardmaessig nur dem Autor und nicht der Liste schreibt. Da es vielleicht andere auch interessant, poste ich nun meine Mail an Andre noch mal an die Liste. Hallo Andre.
Das GUI soll "multiuser fähig" werden, nun denken ich das es ein kleiner Performanzgewinn sein könnte, wenn der Client keine Rechenoperationen mehr machen muss.
Reden wir hier von 1 bis 5 Users oder von 1000? (-;
Ich denke so bis 50 ist realistisch?? Habe ich mir ehrlich gesagt noch nicht genau überlegt!
Je mehr je besser :)
Was ist den bei vielen Usern besser, die Last auf den Server oder im Client?
Pauchal unbedingt der Client. Alles, was der Client tut, entlastet erst mal den Server. Zu bedenken ist dabei aber der Aufwand, der fuer den Server anfaellt, um dem Client die Daten zur Verfuegung zu stellen. Nimmt das ueberhand, dann belastet es auch den Server entsprechend. Und der Benutzer freut sich an nicht, wenn das System staendig Daten hin und herschieb und er entsprechend warten muss. Und dann natuerlich das Thema mit der Aktualitaet der Daten. Die sind bei multi-user auf dem Server immer aktueller als im Client. Da brauchst Du einfach ein Haendchen und eine Portion Erfahrung. Und am meisten Erfahrung bekommst Du, wenn Du versuchst, solche Fragen selbst zu klaeren. Wenn Du nicht weisst, ob A schneller ist oder B, dann probier beides mal aus und miss die Zeit.
Was bietet JDBC an Sicherheitsmechanismen für die Übertragung, z.B. gegen manipulierte Statements? Oder in anderen Worten: Wer verhindert, dass ein manipulierter Client ein "DROP TABLE kundendaten" schickt?
Gute Frage, per default wird alles in Klartext sein... (???)
Wenn JDBC fuer den Client-Server Einsatz gedacht ist, muss es da irgendwelche Sicherheitsmechanismen gehen. Sonst kommst Du ja in Teufels Kueche bzw. eigentlich kommst Du gar nirgends hin.
Und wie funktioniert die Anmeldung? Die Zugangsdaten werden ja wohl kaum im Applet stehen. Oder doch?
Es wird kein Applet geben. Auf dem Internetserver wird nur Apache mit mod_jk/tomcat laufen. Mysql natülich auch. Nur der Shop direkt ist manipulierbar, z.B. in den jemand versucht die Servlets zu steuern.
Ach so. Also ein schlichtes Browser-Backend/Frontend? Da habe ich das Client-Server-Thema ueberbewertet.
Das UI muss ich mit Swing machen (leider gibt's QT nur als eval für M$) und ist zum Artikel rein hacken in eine "lokale DB" gedacht.
Also doch ein Applet fuer das Backend?
Der Abgleich mit der DB auf dem I-Server wollte ich mittels SSH und XML lösen, vielleicht auch mit sql.txt. Das würde mit putty bzw pscp auf M$ ganz gut klappen. Mit Java gibt es allerdings auch eine API, womit man RSA & Co. benutzen kann.
Allgemein ist es sicherer, wenn der Client keinen direkten Zugriff auf die Datenbank hat. Also am besten Servlets aufrufen und denen sagen, was zu tun ist. Und dabei keine SQL-Statements verwenden, sondern Parameter uebergeben. Die sind leichter zu ueberpruefen. Und immer im Hinterkopf behalten: Java-Klassen koennen dekompiliert werden. Also auf keinen Fall Passwoerter oder aehnlich sensible Daten hartcodiert in Javacode, der beim Benutzer laeuft und somit den Server verlaesst. Und wenn solche Daten uebers Internet nachgeladen werden, ist wiederum zu bedenken, dass der Bytecode dekompiliert werden kann. Es ist als moeglich, dass jemand den Code dekompiliert, sich abaendert und sich dann Daten ausgeben laesst, die eigentlich niemand sehen sollte. Aber bei Open Source muss man ja nicht mal dekompilieren (-; Es ist schon viel zu bedenken, wenn man sich bei serverseitigem CGI keine Sicherheitsluecken einbauen will. Wenn dann noch ein Client dazukommt, wird es noch schwieriger. Und bei Shops geht's natuerlich auch um Geld. Hat man einen Bug in einer Forum-Software, dann fehlen vielleicht mal ein paar Beitraege. Aber wenn Kundendaten geklaut werden oder Daten von gelieferten und noch nicht bezahlten Waren verloren gehen, dann ist der Aerger gross. Da sollte man sich unbedingt mit gaengigen Sicherheitsmechanismen vertraut machen. Und zwar nicht zu wissen, welche es gibt, sondern auch wo ueblicherweise die Schwachstellen sind, an denen man sie einsetzt. Viel Spass (-; -- 1 Bodo Kaelberer 123 http://www.webkind.de/ 3 4 Politik ist, wenn viele sich streiten und keiner sich freut.
Am Mittwoch, 17. März 2004 16:02 schrieb Bodo Kaelberer:
Ich weiss nicht, wieso diese Liste so konfiguriert ist, dass man standardmaessig nur dem Autor und nicht der Liste schreibt. Da es vielleicht andere auch interessant, poste ich nun meine Mail an Andre noch mal an die Liste.
IMHO ist Deine Mail korrekt in der Liste angekommen, mir ist jedenfall nichts aufgefallen...
Das GUI soll "multiuser fähig" werden, nun denken ich das es ein kleiner Performanzgewinn sein könnte, wenn der Client keine Rechenoperationen mehr machen muss.
[...]
Was ist den bei vielen Usern besser, die Last auf den Server oder im Client?
Pauchal unbedingt der Client. Alles, was der Client tut, entlastet erst mal den Server. Zu bedenken ist dabei aber der Aufwand, der fuer den Server anfaellt, um dem Client die Daten zur Verfuegung zu stellen. Nimmt das ueberhand, dann belastet es auch den Server entsprechend. Und der Benutzer freut sich an nicht, wenn das System staendig Daten hin und herschieb und er entsprechend warten muss.
Hmm, meine Meinung geht jetzt dahin, alle Berechnungen im Client zumachen.
Und dann natuerlich das Thema mit der Aktualitaet der Daten. Die sind bei multi-user auf dem Server immer aktueller als im Client.
Was bietet JDBC an Sicherheitsmechanismen für die Übertragung, z.B. gegen manipulierte Statements? Oder in anderen Worten: Wer verhindert, dass ein manipulierter Client ein "DROP TABLE kundendaten" schickt?
Gute Frage, per default wird alles in Klartext sein... (???)
Wenn JDBC fuer den Client-Server Einsatz gedacht ist, muss es da irgendwelche Sicherheitsmechanismen gehen. Sonst kommst Du ja in Teufels Kueche bzw. eigentlich kommst Du gar nirgends hin.
Und wie funktioniert die Anmeldung? Die Zugangsdaten werden ja wohl kaum im Applet stehen. Oder doch?
Es wird kein Applet geben. Auf dem Internetserver wird nur Apache mit mod_jk/tomcat laufen. Mysql natülich auch. Nur der Shop direkt ist manipulierbar, z.B. in den jemand versucht die Servlets zu steuern.
Ach so. Also ein schlichtes Browser-Backend/Frontend? Da habe ich das Client-Server-Thema ueberbewertet.
Das UI muss ich mit Swing machen (leider gibt's QT nur als eval für M$) und ist zum Artikel rein hacken in eine "lokale DB" gedacht.
Also doch ein Applet fuer das Backend?
Nein ... Soll ein Backend für den Desktop werden, läuft in keinem Browser. SWT werde das zu mal probieren ...
Der Abgleich mit der DB auf dem I-Server wollte ich mittels SSH und XML lösen, vielleicht auch mit sql.txt. Das würde mit putty bzw pscp auf M$ ganz gut klappen. Mit Java gibt es allerdings auch eine API, womit man RSA & Co. benutzen kann.
Allgemein ist es sicherer, wenn der Client keinen direkten Zugriff auf die Datenbank hat. Also am besten Servlets aufrufen und denen sagen, was zu tun ist. Und dabei keine SQL-Statements verwenden, sondern Parameter uebergeben. Die sind leichter zu ueberpruefen.
Und immer im Hinterkopf behalten: Java-Klassen koennen dekompiliert werden. Also auf keinen Fall Passwoerter oder aehnlich sensible Daten hartcodiert in Javacode, der beim Benutzer laeuft und somit den Server verlaesst. Und wenn solche Daten uebers Internet nachgeladen werden, ist wiederum zu bedenken, dass der Bytecode dekompiliert werden kann. Es ist als moeglich, dass jemand den Code dekompiliert, sich abaendert und sich dann Daten ausgeben laesst, die eigentlich niemand sehen sollte. Aber bei Open Source muss man ja nicht mal dekompilieren (-;
Es ist schon viel zu bedenken, wenn man sich bei serverseitigem CGI keine Sicherheitsluecken einbauen will. Wenn dann noch ein Client dazukommt, wird es noch schwieriger.
Und bei Shops geht's natuerlich auch um Geld. Hat man einen Bug in einer Forum-Software, dann fehlen vielleicht mal ein paar Beitraege. Aber wenn Kundendaten geklaut werden oder Daten von gelieferten und noch nicht bezahlten Waren verloren gehen, dann ist der Aerger gross.
Da sollte man sich unbedingt mit gaengigen Sicherheitsmechanismen vertraut machen. Und zwar nicht zu wissen, welche es gibt, sondern auch wo ueblicherweise die Schwachstellen sind, an denen man sie einsetzt.
Wie wahr, wie wahr, wie wahr ...
Viel Spass (-;
Und viel Arbeit ;) Ciao Andre
Am Dienstag, 16. März 2004 17:38 schrieb Andre Heine:
Moin moin alle zusammen,
ich programmiere gerade einen Webshop in Java mit GUI für den Desktop (Artikelpflege, Administration, multiuserfähig, Einbindung in Confixx, XML Schnittstelle, Open-Source natürlich).
Meine Frage ist nun, ob es besser ist Rechenoperationen der Mysql DB zu überlassen oder besser dem Java Programm.
Ich würde mal sagen, das hängt davon ab. Wenn Du es der Datenbank überlässt, kannst Du eventuell massiv den Datentransfer reduzieren, das spart eine Menge Zeit, wenn die Daten übers Netz laufen, also Programm und DB-Server nicht auf der selben Kiste laufen. Auch müssen die ganzen Felder von Datenbankfeldern nach Java-Variablen konvertiert werden, auch das kostet Zeit. Im Gegenzug muss freilich ein größeres SQL-Statement geparsed werden. Das lässt sich allerdings per Prepared Statements wieder recht gut ausgleichen. Ich bevorzuge Berechnungen in der DB wenn: - sich massiv Datenvolumen einsparen lassen - fertige Funktionen zur Verfügung stehen (Extremes Beispiel, ein 'SELECT COUNT(*) FROM XYZ' würde ich nicht in Java nachbilden) Wenn das Datenvolumen ähnlich bleibt, mit ein und der selben Variable eventuell mehr berechnet wird und das SQL-Statement deutlich vereinfacht wird, würde ich ne Java-Implementierung vorziehen. Ein Vorteil der dadurch recht einfachen SQL-Statements dürfte auf jeden Fall beim Datenbankwechsel ein reduzierter Portierungsaufwand sein. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Dienstag, 16. März 2004 20:29 schrieb Manfred Tremmel:
Am Dienstag, 16. März 2004 17:38 schrieb Andre Heine:
[...]
Meine Frage ist nun, ob es besser ist Rechenoperationen der Mysql DB zu überlassen oder besser dem Java Programm.
Ich würde mal sagen, das hängt davon ab. Wenn Du es der Datenbank überlässt, kannst Du eventuell massiv den Datentransfer reduzieren, das spart eine Menge Zeit, wenn die Daten übers Netz laufen, also Programm und DB-Server nicht auf der selben Kiste laufen. Auch müssen die ganzen Felder von Datenbankfeldern nach Java-Variablen konvertiert werden, auch das kostet Zeit. Im
Zur Zeit habe ich die MySQL Datentypen in java.sql.* konvertiert, die eigentlichen Daten sind Object's... Die Column-Objekte sind als ArrayList in einem Table-Objekt. Alle Daten-Objekte "extenden" das Table-Objekt. Ne' Menge Overhead...
Gegenzug muss freilich ein größeres SQL-Statement geparsed werden. Das lässt sich allerdings per Prepared Statements wieder recht gut ausgleichen.
Ich bevorzuge Berechnungen in der DB wenn: - sich massiv Datenvolumen einsparen lassen - fertige Funktionen zur Verfügung stehen (Extremes Beispiel, ein 'SELECT COUNT(*) FROM XYZ' würde ich nicht in Java nachbilden)
Das ist klar ;) Für einige Berechnungen habe ich verschachtelte Statements gefunden. z.B.: "SELECT CONCAT(vorname, " ", nachname) FROM tabellen_name WHERE einkommen/dependents > 10000 AND age > 30;" Das Stmt ist jetzt zwar nicht lang, aber verschachtelte SELECT/ UPDATE WHERE Stmt's werden recht schnell gross.
Wenn das Datenvolumen ähnlich bleibt, mit ein und der selben Variable eventuell mehr berechnet wird und das SQL-Statement deutlich vereinfacht wird, würde ich ne Java-Implementierung vorziehen. Ein Vorteil der dadurch recht einfachen SQL-Statements dürfte auf jeden Fall beim Datenbankwechsel ein reduzierter Portierungsaufwand sein.
Das ist ein gutes Argument, bislang bin ich eigentlich sehr gut mit Java gefahren. Habe aber sehr schlechte Erfahrungen mit Swing gemacht (LAHM!!). C++ und GUI geht leider nicht aus Kostengründen ;( Ciao Andre
Hi Andre! Andre Heine schrieb:
Am Dienstag, 16. März 2004 17:38 schrieb Andre Heine:
Das ist ein gutes Argument, bislang bin ich eigentlich sehr gut mit Java gefahren. Habe aber sehr schlechte Erfahrungen mit Swing gemacht (LAHM!!).
C++ und GUI geht leider nicht aus Kostengründen ;(
Ich hörte dich in deinen letzten Postings immer wieder über Swing schimpfen - v.a. wegen der Performance. Wenn du kein Applet, sondern eine Standalone-Anwendung programmierst, könntest du auch SWT für die GUI verwenden: Einführung in SWT: http://help.eclipse.org/help21/topic/org.eclipse.platform.doc.isv/guide/swt.... Download-Links: Win32: http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-2.1.2-200311030802/sw... Linux: http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-2.1.2-200311030802/sw... http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-2.1.2-200311030802/sw... In dem Zusammenhang könnte auch JFace für dich interessat werden: http://help.eclipse.org/help21/topic/org.eclipse.platform.doc.isv/guide/jfac... Wenn du eine Beispielanwendung für SWT sehen willst, lade dir doch einfach Eclipse herunter und starte es ;-) Gruß, Michael
Am Mittwoch, 17. März 2004 15:26 schrieb Michael Wenger: [...]
Ich hörte dich in deinen letzten Postings immer wieder über Swing schimpfen - v.a. wegen der Performance. Wenn du kein Applet, sondern eine Standalone-Anwendung programmierst, könntest du auch SWT für die GUI verwenden:
Einführung in SWT: http://help.eclipse.org/help21/topic/org.eclipse.platform.doc.isv /guide/swt.htm Download-Links: Win32: http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-2.1.2-2003 11030802/swt-2.1.2-win32.zip Linux: http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-2.1.2-2003 11030802/swt-2.1.2-linux-gtk.zip http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-2.1.2-2003 11030802/swt-2.1.2-linux-motif.zip
In dem Zusammenhang könnte auch JFace für dich interessat werden: http://help.eclipse.org/help21/topic/org.eclipse.platform.doc.isv /guide/jface.htm
Wenn du eine Beispielanwendung für SWT sehen willst, lade dir doch einfach Eclipse herunter und starte es ;-)
Derzeit arbeite ich mit NetBeans. Eclipse wollte ich aber schon ausprobieren. Das Testen von SWT habe ich mir notiert :) Ciao Andre
Am Mittwoch, 17. März 2004 03:45 schrieb Andre Heine:
Das ist ein gutes Argument, bislang bin ich eigentlich sehr gut mit Java gefahren. Habe aber sehr schlechte Erfahrungen mit Swing gemacht (LAHM!!).
Kann ich nichts zu sagen, ich hab einmal ein kleines AWT-GUI-Programm geschrieben, ansonsten nur Servlets. Von der Geschwindigkeit von Java hört man ja immer sehr extreme Positionen. Wenn ich selber teste, kann ich das nachvollziehen. Sun's Forte bzw. die freie Version Netbeans hab ich auch auf nem 1 GHz Celeron nie über Griechtempo hinaus gekriegt, während Borlands JBuilder auch auf meinem PowerBook G3 (266 MHz) angenehm flott läuft. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Mittwoch, 17. März 2004 20:10 schrieb Manfred Tremmel:
Am Mittwoch, 17. März 2004 03:45 schrieb Andre Heine:
Das ist ein gutes Argument, bislang bin ich eigentlich sehr gut mit Java gefahren. Habe aber sehr schlechte Erfahrungen mit Swing gemacht (LAHM!!).
Kann ich nichts zu sagen, ich hab einmal ein kleines AWT-GUI-Programm geschrieben, ansonsten nur Servlets. Von der Geschwindigkeit von Java hört man ja immer sehr extreme Positionen. Wenn ich selber teste, kann ich das nachvollziehen. Sun's Forte bzw. die freie Version Netbeans hab ich auch auf nem 1 GHz Celeron nie über Griechtempo hinaus gekriegt, während Borlands JBuilder auch auf meinem PowerBook G3 (266 MHz) angenehm flott läuft.
Viel kommt bestimmt auch auf den Style an, ich muss mir mal "Java Effektiv Programmieren" besorgen. Die Umfang der API ist enorm, man kann oft bestimmte API's falsch einsetzen. Ich werd' mal sehen wie die API von SWT aussieht, ansonsten nehm' ich einfach SWING. Bye Andre
participants (7)
-
Andre Heine -
Bodo Kaelberer -
George Stoianov -
Lars Hermes -
Manfred Tremmel -
Michael Rauter -
Michael Wenger