# SELECT oder Programm-Logik



## Willi2793 (27. Aug 2012)

Hallo,

ich habe eine Datenbank und möchte gerne diverse Statistiken ausgeben. Nun stellt sich mir die Frage ob ich diese Statistiken bzw. tabellen durch große SELECTs erstelle oder doch lieber durch einfache SELECTs und die eigentliche Tabelle durch Programm-Logik erstelle.

Das ganze läuft auf einer MySQL-Datenbank.

Danke und Grüße,
Willi


----------



## SlaterB (27. Aug 2012)

was soll man dazu sagen, entweder nervst du die DB oder das eigene Programm, 
läuft nicht beides auf den gleichen Rechner, sondern die DB z.B. auf einen Super-Duper 3000 mit 999 MMMHz, 
dann ist diese Entscheidung für sich schon sehr relevant, bei eigenen Rechner weniger

natürlich ist auch die Ausdruckskraft in SQL eine Frage, in Java theoretisch unbegrenzt mit allen möglichen Hilfsdatenstrukturen,
dazu gehört dann freilich auch ob man selber besser SQL oder Java beherrscht,
interessant ist ob der Code bzw. die Klassen in den die Daten überführt werden könnten, schon da ist oder sowieso noch gebraucht wird

usw., mal ehrlich, das klingt jetzt schon nach einigem, aber da war doch jetzt nichts dabei was du dir nicht selber denken kannst, oder? 
ich schreibe nur weil nach 5 Stunden nicht ganz zu befürchten ist, dass evtl. bessere Antworten verdrängt werden

edit:
fertig berechnete Daten, ob per SELECT oder Programm gewonnen, in Tabellen zu speichern ist fast für sich eine Frage,
man gewinnt Zeit bei der Abfrage, Ergebnisse auslesen statt erst zu berechnen ist meist schneller (aber nicht zwingend, nicht blind verfolgen),
dafür in der Regel mehr Speicherplatz nötig, Aufwand beim Einfügen + Ändern,

der klassische Gegensatz: Standard-Aufwand gegen Vorteil im 'Ernstfall'


----------



## Willi2793 (27. Aug 2012)

Danke für Deine Meinung. Ich denke ja auch das es nicht unbedingt ganz genau zu spezifizieren ist. Und ja, da waren auch viele meiner Gedanken dabei. Aber ich dachte das vielleicht eine Diskussion auch nochmal ganz neue Gedanken oder Argumente bringt.


----------



## gp (27. Aug 2012)

Mein ganz pauschal gesagt: vermeide Zugriffe auf die Datenbank, wann immer es geht. Nicht ganz ernst gemeint, aber vom Kern her: Datenbankzugriffe kosten Zeit, Operationen im RAM sind schnell. Klar, genug RAM sollte da sein.

Ein Beispiel aus meiner Praxis, als damals erste Gehversuche: ich lies per Schleife Daten aus einer MySql-Datenbank. War kein Problem mit meinen Testdaten. Als die Schleife dann in der Praxis auf ca. 1000 Durchläufe stieg, war schon ne kleine Kaffeepause nötig. Lösung: vor der Schleife alles lesen und den Rest Java machen lassen. Jetzt war wieder alles gut (und RAM war genug dafür da),

Aber: ohne konkrete Anforderungen ist alles nur Theorie. In der Praxis hilft nur messen (und schätzen), bevor es dann los geht.

Genug der Philosophie für heute abend 

Günter


----------



## Willi2793 (28. Aug 2012)

Das ist klar. Wenn ich für meine Auswertung die Alternative hätte entweder eine Schleife über einen kleinen SELECT und den Satz verarbeiten oder einen SELECT und Schleife über das ResultSet wäre es klar. Aber ich habe einen Riesen-Select der einmal ausgeführt wird oder halt 2-3 kleine und dann Schleifen über die ResultSets.


----------



## tfa (28. Aug 2012)

Eine pauschale Aussage kann man hier nicht machen. Wenn für die Statistik Daten benötigt werden, die über zig Tabellen verteilt sind, ist eine komplexe SQL-Query sicherlich effektiver, als die halbe DB erst in den Speicher zu laden und dann rumzurechnen. Was besser ist, muss man von Fall zu Fall entscheiden.


----------



## gp (28. Aug 2012)

Willi2793 hat gesagt.:


> Aber ich habe einen Riesen-Select der einmal ausgeführt wird oder halt 2-3 kleine und dann Schleifen über die ResultSets.


Mein Tipp: erst mal so einfach wie möglich programmieren - der SQL-Spezialist wählt sicher das komplexe SELECT der Java-Profi vielleicht den anderen Weg.

Dann mit Produktionsdaten testen (also nicht mit einer fast leeren Datenbank). Wenn alles schnell genug läuft, bist du fertig - ansonsten den Flaschenhals suchen und den gezielt optimieren.

Ohne probieren ist das alles nur Theorie - trotz aller Erfahtung hatte ich heute geanau so ein Problem. Eine eigentlich recht einfache Abfrage dauerte Minuten. Ohne SQL-Sortierung war alles OK. Das Nachsortieren in Java kostete dann keine Zeit - und manchmal ist es halt doch wieder anders.

Günter


----------



## r.w. (29. Aug 2012)

gp hat gesagt.:


> ...Eine eigentlich recht einfache Abfrage dauerte Minuten. Ohne SQL-Sortierung war alles OK. Das Nachsortieren in Java kostete dann keine Zeit - und manchmal ist es halt doch wieder anders...



Wenn die Sortierung per SQL-Statement zu lange dauert, würde ich mir eher Gedanken 
über die Optimierung der Datenbank, in diesem Fall speziell der Indizes, machen.

Sollte eine Abfrage direkt auf dem Server machbar sein, wird sie in der Regel auch
schneller sein, als die Client-seitige Nachbildung in Java, oder worin auch immer. 
Es sei den der Server erfüllt nicht die Voraussetzungen für diese Datenbank.
Ich rede allerdings nur von "echten" Datenbanksystemen, wie z.B. mySQL, MS SQL, 
Oracle usw. 

Client-seitige Zugriffe sollte man natürlich minimieren, u.A. weil sie auf die Netzlast gehen. 
Genau dazu braucht man ja durchdachte SQL-Statements die die Ergebnismenge bereits 
weitgehend filtern und sortieren, bevor der Client ins Spiel kommt.


----------



## gp (29. Aug 2012)

r.w. hat gesagt.:


> Wenn die Sortierung per SQL-Statement zu lange dauert, würde ich mir eher Gedanken über die Optimierung der Datenbank, in diesem Fall speziell der Indizes, machen.


Klar - auf der grünen Wiese kein Problem. In diesem Fall war mir der Zugriff auf die (fremde) Datenbank leider verwehrt - und an meine neue Abfrage hatte vor 10 Jahren noch keiner gedacht.

Ob eine Datenbank in jedem Fall schneller sortiert als eine Java-Routine, sei mal dahin gestellt. Erfahrungsgemäß schenkt sich das in der Praxis wenig (wenn der Index passt ...).

Günter


----------



## r.w. (29. Aug 2012)

gp hat gesagt.:


> Klar - auf der grünen Wiese kein Problem. In diesem Fall war mir der Zugriff auf die (fremde) Datenbank leider verwehrt - und an meine neue Abfrage hatte vor 10 Jahren noch keiner gedacht.
> 
> Ob eine Datenbank in jedem Fall schneller sortiert als eine Java-Routine, sei mal dahin gestellt. Erfahrungsgemäß schenkt sich das in der Praxis wenig (wenn der Index passt ...).
> 
> Günter



Wieso "grüne Wiese"? 
Gerade bei bestehenden, größeren Datenbanken kann man oft über die 
geschickte Anlage von Indizes eine Menge herausholen. Wenn Du keinen
administrativen Zugriff auf die DB hast, hilft Dir das natürlich nicht weiter. ;-)

Und gerade wenn passende Indizes gesetzt werden, sollte sich das in der Praxis 
zu Gunsten der Serverseite auswirken. Voraussetzung dafür ist natürlich, dass 
das SQL-Statement so formuliert wird, dass es die existierenden Indizes auch nutzt. 
Sonst kann man genauso gut im Client sortieren.

Trotz allem sollte man sollte jedoch mit der Neuanlage von Indizes sparsam sein, 
weil sich der Nutzen auch umkehren kann. Denn was für das Lesen und Sortieren 
einen Geschwindigkeitsvorteil bringt, wirkt sich bei Schreibvorgängen eher negativ 
aus, weil dort alle Indizes vom DBMS mitgepflegt werden müssen. 
Die Entscheidung für bzw. gegen Indizes kann also zum Teil auch vom Verhältnis 
der Anzahl an Schreibvorgängen zur Anzahl der Lesevorgänge abhängig gemacht 
werden.


----------



## Willi2793 (30. Aug 2012)

Vielen Dank Euch Allen. Das waren doch schonmal ein paar Denkanstöße :toll:


----------

