Geschwindikeit Datenbankabfragen

Community DE
1

Hallo!

Also ich hab mir gedacht: biste klug und baust deine Seitenlangen
Datenbankabfragen(SQL QUERRYS) um. Anstatt zigmal das selbe aus der
Datenbank abzufragen habe ich mir dann alle Datensätze auf einmal in ein
Array geholt z. B. : ( @project = Project.find(:all) ) um dann im Array
@project meine Suchabfragen zu machen.

Nun habe ich aber nicht den Eindruck, dass das schneller geht. Ganz im
Gegenteil.

Wie sind denn da eure Erfahrungen?

Gruß Ortwin

2

Hallo Ortwin,
wie viele Daten holst Du denn in die @project-Variable?

Eine Datenbank ist ja nun gerade darauf spezialisiert, mittels einer
Abfragesprache, die richtigen Datensätze aus einer großen Menge von
Daten zu
extrahieren, zu sortieren, etc.

Wiederholungen vermeidest Du wohl besser, indem Du Deine Queries
wiederverwertbar gestaltest.

Besten, etwas verwunderten Gruß

Jan

Am 2. September 2008 21:28 schrieb Holger Hänisch
[email protected]:

–
Jan P.
Rechtsanwalt

Babendiekstraße 60 B
22587 Hamburg
Tel +49 (0)40 41265809 Fax +49 (0)40 380178-73022
Mobil +49 (0)171 3516667

3

Hallo,

das Verhalten hängt von vielen Faktoren ab, Geschwindigkeit, Anbindung
der Datenbank, Umfang der Ergebnismenge etc.
Im Allgemeinen sollte man das Resultset möglichst klein halten, da der
Datentransport über das Netzwerk eher ein Bremse darstellt als die
Abfrage der Daten selbst. Die Datenbank selbst kann besser Abfragen
optimieren und Daten cachen als Du das mit erträglichem Aufwand lokal
hinkriegst. Zudem ist das Holen und Speichern “auf Verdacht” ein
Antipattern, da Du so schnell unnötg Konflikte erzeugen kannst (Lokale
Daten vs. zwischenzeitlich geänderte Daten)

Daher: Sieh Dir die Anfragen an, die Du über ActiveRecord auf der
Datenbank erzeugst (AR-Logging einschalten!) und versuche die
Ergebnismenge möglicht klein zu halten und laß die Datenbank die
Arbeit machen für die sie optimiert ist (Filtern, Suchen, Joins). Wenn
das Ganze zu langsam ist, dann beschäftige Dich mit den Themen
Fremdschlüssel und Indizes. Prüfe ob die von AR erzeugten Abfragen
entsprechend optimal sind …

Es gibt wirklich selten Fälle bei denen eine richtig eingesetzte
Datenbank ein echter Flaschenhals ist.

Viele Grüße & Erfolg,
Peter

Am 02.09.2008 um 21:28 schrieb Holger Hänisch:

4

Wir habe gerade auf einer Schulung ein ähnliches Thema behandelt. Ich
kann dir nicht 100% sagen ob es für MySQL gültig ist aber so sieht es
bei ORCL Datenbanken aus.

Du musst unterscheiden, ob du die selects über einen full table scan
machst oder index basiert ziehst. Bei funktionsbasierten selects
(functionbased querys) greifen allerdings die von dir zuvor für die
Tabellen angelegten index nicht und es wird jedes mal ein full table
scan gemacht.
Solltest du innerhalb der selects irgendwelche Datenbankfunktionen wie
sum,min,max,avg oder irgendwas der gleichen verwenden, dann könnte hier
ein ansatzpunkt liegen. (Wie gesagt, alles erstmal aus ORCL Sicht, ob es
bei MYSQL, ähnlich ist ??? )

Die Datenbank ist in den seltensten Fällen der Flaschenhals. Oft sind es
die Disks mit I/O und auch die Programmierung der selects (leider viel
zu oft mit - full table scans) sind je nach Tabellengröße und
Ergebnismenge selten gut.

Ich muss aber Peter recht geben, dass du vielleicht dein Design
prüfen solltest.

Mario
aka schroedi

PeterDickten wrote:

Daten vs. zwischenzeitlich geänderte Daten)
Datenbank ein echter Flaschenhals ist.

Datenbankabfragen(SQL QUERRYS) um. Anstatt zigmal das selbe aus der

–

Mario Schröder | http://www.poppster.de
Phone: +49 34464 62301 Cell: +49 163 27 09 807
PGP-Key: follows

5

Vielen Dank für die Infos und Hinweise.

Ich werde versuchen eine Mischung aus beiden Ansätzen zu fahren.

Um konkret zu werden:

ich muss ein Arbeitszeitmodel abbilden. Diese Arbeitszeitmodel hat 5
Schichten (Früh, Nacht …). Es wiederholt sich alle 5 Wochen (läuft
aber nicht in einem wöchentlichen Wechsel). Ich gehe im Moment so vor,
dass ich das Model (Datenbank) für 5 Wochen gespeichert habe.

Dann gehe ich z. B. vom heutigen Datum aus. Suche nach diesem Datum in
der Datenbank, finde es nicht, ziehe 35 Tage vom Datum ab, suche wieder
in der Datenbank danach, finde es wieder nicht, bis ich es dann
irgendwann gefunden habe.

Funktioniert sehr gut. Nur wenn ich einen Schichtplan für einen Monat
wie den September erstelle, habe ich für jeden Tag zigmal die
Datenbankabfragen. So habe ich mir gedacht, ich lese die Daten einfach
in eine @variable ein und hol mir die Infos aus dieser Array.

Gut oder nicht gut? Was denkt ihr?

Gruß Ortwin