Re: Re: [pgsql-de-allgemein] viele kleine queries vs wenige große queries

* Michael Prochaska <michael(at)prochas(dot)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 == 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/
---------------------------------------------------------------------