[52411] in SAPr3-news
Re: Optimierung eines select Statements
daemon@ATHENA.MIT.EDU (Rainer Huebenthal)
Tue Nov 23 02:47:36 2004
To: sapr3-news@mit.edu
Date: Tue, 23 Nov 2004 08:33:33 +0100
From: Rainer Huebenthal <usenet200411.20.finji@spamgourmet.com>
Message-ID: <1gufg90b4pq1c.dlg@news.reisetraeume.com>
Reply-To: usenet-reply.20.finji@spamgourmet.com
Moin Wulf Kruempelmann, du schriebst:
> Was ist an DB-Queries schlecht?
Nicht. Das * an Select ist boese. Statt genau zu sagen was man
braucht, holt man lieber alles in den Applikationsserver und
beackert es dort und schmeisst alles weg was man nicht
braucht.
> Die Alternative, mit einem inner join zu arbeiten ist bei großen
> Tabellen sehr oft sehr langsam.
Dann legt man sich einen oder auch mehrere Indexe an. Das man
die Problematik in den Applikationsserver verlagert
verschlimmert alles nur noch.
> Einige Datenbanken bilden einen Inner join so ab, daß sie beide Tabellen
> nehmen und im Temp-Tablespace die Tabellen ausmultiplizieren und dann
> aus dieser Zwischentabelle selektieren.
Im Applikationsserver ist das anders?
> Das wird dann so langsam, daß man echte Probleme bekommt.
> Und die hier benutzten Tabellen sind oft sehr groß.
Das Problem trifft dich im Applikationsserver genauso, evtl
viel schlimmer, da man
-oft mehr Daten holt als notwenig
- öfter Datenbankabfragen absetzt als nötig.
Letztens hab ich wieder gesehen, wie jemand ein Select * auf
eine ganze Tabelle abgesetzt hat, diese im ABAP sortiert um
dann den ersten als einzigen Satz verabreitet hat. Bei sowas
wird mir nur schlecht, wenn ich sowas sehe. Ein kurzer
knackiger Subselct waere wesentlich performanter gewesen.
cu
Rainer
--
http://www.reisetraeume.com
