hallo,

welcher ansatz ist für eine GUI eurer meinung nach im allgemeinen
performanter?


1) die queries schön klein halten (wenn möglich komplett ohne joins) =
und
dafür viele queries =3D> ich hole mir wirklich immer nur das was ich
brauche und habe damit wenig overhead

2) ein großes query mit dem alles erschlagen wird =3D> nur eine
db-connection, dafür aber ev. viel overhead (daten die ich gar nicht
immer brauche)

was sagt ihr dazu?

mfg,
michael



--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

am Mon, dem 17.03.2008, um 15:28:22 +0100 mailte Michael Prochaska folge=
ndes:
> hallo,
>
> welcher ansatz ist für eine GUI eurer meinung nach im allgemeinen
> performanter?
>
>
> 1) die queries schön klein halten (wenn möglich komplett ohne joins=
) und
> dafür viele queries =3D> ich hole mir wirklich immer nur das was ich
> brauche und habe damit wenig overhead
>
> 2) ein großes query mit dem alles erschlagen wird =3D> nur eine
> db-connection, dafür aber ev. viel overhead (daten die ich gar nicht
> immer brauche)

Ich übersetz mal, Beispiel eine Rechnungs-Anwendung mit Rechnungskopf
und Positionen: (ich hoffe, ich hab dich richtig verstanden)


1) 2 kurze 'select * from rechnung_kopf' und 'select * from
rechnung_position' und prüfe dann in der Anwendung, welche Positione=
n
zur Rechnung 4711 gehören

2) ein langes select 'select a.datum, a.adresse, b.position, b.artikel,
b.preis from rechnung_kopf a left join rechnung b on
a.nr=3Db.rechnung_nr where a.rechnung_nr =3D 4711;'


Zur wahrscheinlich Deiner Verwunderung wird 2) nicht nur erheblich
schneller ausgeführt (bei bassenden Indexen), sondern es ist auch der
Aufwand zur =DCbertragung der Daten übers Netz deutlich geringer, Du ha=
st
weniger Arbeit in der Applikation und Du schonst die Platten des
DB-Servers. Klingt lustig, ist aber so.



Fall ich Dich falsch verstanden habe, sorry. Vielleicht schilderst Du
mal besser, was Du planst.

PS.: EXPLAIN kennst Du?



Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Michael Prochaska <michael [at] prochas.net> wrote:

> welcher ansatz ist für eine GUI eurer meinung nach im
> allgemeinen performanter?

> 1) die queries schön klein halten (wenn möglich komplett
> ohne joins) und dafür viele queries =3D> ich hole mir wirklich
> immer nur das was ich brauche und habe damit wenig overhead

> 2) ein großes query mit dem alles erschlagen wird =3D> nur
> eine db-connection, dafür aber ev. viel overhead (daten die
> ich gar nicht immer brauche)

> was sagt ihr dazu?

Selber benchmarken/profilen. Alles andere ist Esoterik.

Tim

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Michael Prochaska schrieb:

> was sagt ihr dazu?

Ich kann jetzt wenig zum DB-Teil selbst sagen, aber "viele kleine
Queries" sind bei hohen bzw. merkbaren Netzwerk-Latenzen zum Server hin
immer problematischer als wenig große.

lg,
michael

--

Michael Renner
InQnet GmbH
Praterstraße 31
A-1020 Wien

Tel.: +43 1 212 7650 521
Fax.: +43 1 212 7650 610

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

> Ich übersetz mal, Beispiel eine Rechnungs-Anwendung mit Rechnungskopf
> und Positionen: (ich hoffe, ich hab dich richtig verstanden)
>
>
> 1) 2 kurze 'select * from rechnung_kopf' und 'select * from
> rechnung_position' und prüfe dann in der Anwendung, welche Positio=
nen
> zur Rechnung 4711 gehören
>
> 2) ein langes select 'select a.datum, a.adresse, b.position, b.artikel,
> b.preis from rechnung_kopf a left join rechnung b on
> a.nr=3Db.rechnung_nr where a.rechnung_nr =3D 4711;'
>
>
> Zur wahrscheinlich Deiner Verwunderung wird 2) nicht nur erheblich
> schneller ausgeführt (bei bassenden Indexen), sondern es ist auch der
> Aufwand zur =DCbertragung der Daten übers Netz deutlich geringer, Du =
hast
> weniger Arbeit in der Applikation und Du schonst die Platten des
> DB-Servers. Klingt lustig, ist aber so.
>
>
>
> Fall ich Dich falsch verstanden habe, sorry. Vielleicht schilderst Du
> mal besser, was Du planst.
>
> PS.: EXPLAIN kennst Du?
>
>

ich habe alles was mit personen zu tun hat (personal, kunden,....) in
subjekte (adresse, bankverbindung,....), personen (namen,...),
firmen(bezeichnung), personal, kunden, usw aufgeteilt...weiters habe ich
eine auftragstabelle und eine rechnungstabelle....dazwischen habe ich
noch diverse zwischentabellen um kunden bzw. personal mit aufträgen zu
verknüpfen.


wenn ich jetzt z.B.: alle daten für eine rechnung brauche, dann muss ic=
h
da ganz schön herumjoinen.

es gibt dann z.B: auch die möglichkeit das die rechnung an eine firma
geht, es allerdings eine person als ansprechperson gibt.
wenn der rechnungsempfänger (die person) keine adressdaten hat, dann
muss ich die adressdaten des rechnungsträgers (der firma) nehmen.


daher meine frage: vereinzelt infos holen um entscheidungen treffen zu
können und dann dementsprechend nur daten holen die ich auch brauche,
oder alles in einem riesigen join holen und dann nur das verwenden was
ich brauche.


ich hoffe es ist jetzt klarer....

mfg,
michael

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Michael Prochaska <michael [at] prochas.net> schrieb:
> >PS.: EXPLAIN kennst Du?
> >

ich stelle die Frage noch einmal.

>
> ich habe alles was mit personen zu tun hat (personal, kunden,....) in
> subjekte (adresse, bankverbindung,....), personen (namen,...),
> firmen(bezeichnung), personal, kunden, usw aufgeteilt...weiters habe ic=
h
> eine auftragstabelle und eine rechnungstabelle....dazwischen habe ich n=
och
> diverse zwischentabellen um kunden bzw. personal mit aufträgen zu
> verknüpfen.

klingt gut normalisiert.

>
>
> wenn ich jetzt z.B.: alle daten für eine rechnung brauche, dann muss =
ich da
> ganz schön herumjoinen.

das hat ein normalisiertes Design so an sich.

>
> es gibt dann z.B: auch die möglichkeit das die rechnung an eine firma=
geht,
> es allerdings eine person als ansprechperson gibt.
> wenn der rechnungsempfänger (die person) keine adressdaten hat, dann =
muss
> ich die adressdaten des rechnungsträgers (der firma) nehmen.
>
>
> daher meine frage: vereinzelt infos holen um entscheidungen treffen zu
> können und dann dementsprechend nur daten holen die ich auch brauche,=
oder
> alles in einem riesigen join holen und dann nur das verwenden was ich
> brauche.

Ich schließe mich Tim an, mit dem Einwand, daß relationale Datenbanke=
n
nun mal von den Beziehungen zwischen den Tabellen leben und dahin
optimiert sind. Aus dem Bauch heraus: ein guter Joint, ups, ohne t, ist
besser als rumgekraute in der DB. Vermutlich optimiert die DB die
Beziehungen zwischen den Tabellen erheblich besser als Deine externe
Anwendung, die z.B. auf wichtige Daten aus pg_stats verzichten muß.

Falls Du meinst, das besser zu können: Tom 'tgl' Lane freut sich
bestimmt über Hilfe...

Btw.: wenn Du 'alles in einem riesigen join holen' tust, um dann 'nur
das verwenden was ich brauche' machst Du möglicherweise auch was falsch=
..


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknow)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Andreas Kretschmer schrieb:
> Michael Prochaska <michael [at] prochas.net> schrieb:
>
>>> PS.: EXPLAIN kennst Du?
>>>
>>>
>
> ich stelle die Frage noch einmal.
>

ja, kenne ich.
ich gehe aber momentan nicht davon aus das ich performanceprobleme
bekomme, egal welche variante....daher wollte ich mir den aufwand nicht
antun beide varianten auszuprogrammieren...

und ich glaube dass tipps von alten "postgres hasen" mehr aussagekraft
haben als eine minimal-benchmark :-)
(1 x gejointe query vs 2 x einzelne queries)



>> Ich schließe mich Tim an, mit dem Einwand, daß relationale Datenba=
nken
>> nun mal von den Beziehungen zwischen den Tabellen leben und dahin
>> optimiert sind. Aus dem Bauch heraus: ein guter Joint, ups, ohne t, is=
t
>> besser als rumgekraute in der DB. Vermutlich optimiert die DB die
>> Beziehungen zwischen den Tabellen erheblich besser als Deine externe
>> Anwendung, die z.B. auf wichtige Daten aus pg_stats verzichten muß.
>>
>>

das wollte ich hören :-)
danke!


MfG,
Michael


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

* Michael Prochaska <michael [at] prochas.net> schrieb:

> daher meine frage: vereinzelt infos holen um entscheidungen treffen zu
> können und dann dementsprechend nur daten holen die ich auch brauche,=

> oder alles in einem riesigen join holen und dann nur das verwenden was
> ich brauche.

Ganz klar: dafür ist das RDMS zuständig (genau deshalb gibts
nimmt man die Dinger ja auch statt eines Karteikasten ;-P).

Vorrausgesetzt, Du schickst immer die passenden Queries (und hast
auch sonst Deine Hausaufgaben als DBA gemacht, dann wird die DB
wohl immer schneller sein - der server kann viel besser entscheiden,
wie er die Daten zusammensucht, als das Dein Client jemals könnte.

Wichtig ist aber, daß Du aber unnötig große Queries vermeidest.
Ergo: definier erstmal die in Frage kommenden access patterns (incl.
der jeweils benötigten Felder) und baue entsprechende Views. Der
Client bekommt dann *ausschließlich* seine Views zu sehen (nebenbei
auch gut für Sicherheit und robuste Entwicklung!) - alles weitere
macht die DB. Optimierungen finden dann innerhalb der DB (an den
entsprechenden RULEs) statt.

Ahja, meist bietet es sich auch an, komplexere Operationen (die keinen
interaktiven Input brauchen), direkt in der DB zu implementieren.
Angenommen, Du hast schon alle nötigen Abrechnungsdaten in der DB
(zB. feste Abo-Preise, oder auch über erfaßte Verbrauchsmengen),
dann bietet es sich an, gleich die Rechnungen von der DB erzeugen
zu lassen. Man könnte es sogar noch soweit treiben und sogar den
Rechnungsversand per Trigger/Rule anzustoßen (wird in großen
Systemen gern mal gemacht).

Ich hab genau das vor ein paar Jahren mal bei einer Börsenhandels-
Plattform umgesetzt. Vorher liefen da allerlei Services, die ständig
jeden kleinen Furz einzeln aus der DB gezogen und wieder gescheiben
haben. Natürlich war das alles grottenlangsam (allein schon durch
das Polling) und alles andere als transaktionssicher. Nachdem ich all
das in Trigger/Rules verpackt hab, lief alles rasend schnell.

Ein RDBMS ist nunmal keine Tabellenkalkulation ;-P


cu
--
------------------------------------------------------------ ---------
Enrico Weigelt =3D=3D metux IT service - http://www.metux.de/
------------------------------------------------------------ ---------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
------------------------------------------------------------ ---------

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein