Hallo!

Ich hätte da mal eine Performance-Frage an die erfahrenen "Datenbankler=
":

Ich möchte mir eine Datenbank-Applikation programmieren, mit der ich Bi=
lder verwalten kann.
Mein Datenbank-Schema sieht vor, dass ich mir mehrere (Bilder-)Kategorien=
anlegen kann. Jede Kategorie kann dann mehrere Alben enthalten. Die einz=
elnen "Bilder" sind dann entsprechend unterhalb der "Alben" zu finden.
Entsprechend habe ich eine Tabelle für Kategorien, eine für Alben und=
eine für Bilder. Wenn ich das Schema normalisiere (sofern ich das rich=
tig gemacht habe) hat jedes Tupel in der Tabelle Alben einen Verweis auf =
die Kategorie, in dem es enthalten ist (foreign key), jedes Bilder-Tupel =
hat entsprechend eine Referenz auf sein Album.
Da ich immer wenn ich ein Bild selektiere, eigentlich auch die zugehöri=
ge Kategorie benötige (die Bilder sind nicht als BLOB/BYTEA in der Date=
nbank, sondern liegen im Dateisystem in Pfaden welche der Struktur Katego=
rie/Album/Bildername folgen), stellt sich mir nun die Frage, ob es nicht =
deutlich effizienter ist, wenn jedes Bild auch noch direkt eine Referenz =
auf seine Kategorie enthält. Theoretisch benötige ich diese ja nicht,=
da ich über die Tabelle Alben auch an die entsprechende Kategorie hera=
nkomme. "Spendiere" ich den Bildern einen eigenen foreign key, benötige=
ich für jedes Bild einen BIGINT mehr an Speicher, andererseits spare i=
ch mir eine Menge JOIN-Operationen (welche ja nicht gerade billig sind).

Ich würde behaupten, die Lösung mit dem zusätzlichen foreign key is=
t erheblich effizienter, allerdings würde mich auch mal die Meinung der=
erfahrenen Benutzer hier interessieren, vielleicht täusche ich mich ja=
?

Würde mich sehr über Antwort freuen!

Vielen Dank & viele Grüße,
Tim
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

am Tue, dem 10.04.2007, um 9:46:25 +0200 mailte "Tim Frießinger" folg=
endes:
> stellt sich mir nun die Frage, ob es nicht deutlich effizienter ist,
> wenn jedes Bild auch noch direkt eine Referenz auf seine Kategorie
> enthält. Theoretisch benötige ich diese ja nicht, da ich über die
> Tabelle Alben auch an die entsprechende Kategorie herankomme.
> "Spendiere" ich den Bildern einen eigenen foreign key, benötige ich
> für jedes Bild einen BIGINT mehr an Speicher, andererseits spare ich
> mir eine Menge JOIN-Operationen (welche ja nicht gerade billig sind).

> ...

>
> Ich würde behaupten, die Lösung mit dem zusätzlichen foreign key =
ist
> erheblich effizienter, allerdings würde mich auch mal die Meinung der
> erfahrenen Benutzer hier interessieren, vielleicht täusche ich mich
> ja?


Ich glaub nicht, daß das sehr teuer ist, zu einem Bild über das Album
die Kategorie zu ermitteln, das Album wirst Du ja eh auch wissen wollen.



Warum probierst Du es nicht mal aus? Erzeug Dir doch mal eine zweite
Tabelle der Bilder _MIT_ diesem FK auf die Kategorie (create table
bilder2 as select ...) und schau mit EXPLAIN ANALYSE, was da bei
rauskommt.


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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Am Dienstag, 10. April 2007 09:46 schrieb Tim Frießinger:
> Da ich immer wenn ich ein Bild selektiere, eigentlich auch die zugehö=
rige
> Kategorie benötige (die Bilder sind nicht als BLOB/BYTEA in der Daten=
bank,
> sondern liegen im Dateisystem in Pfaden welche der Struktur
> Kategorie/Album/Bildername folgen), stellt sich mir nun die Frage, ob e=
s
> nicht deutlich effizienter ist, wenn jedes Bild auch noch direkt eine
> Referenz auf seine Kategorie enthält.

Rein rechnerisch ist es natürlich effizienter, aber wenn du nicht gerad=
e
zehntausende Alben hast, dann lohnt es sich wohl nicht.

Im Zweifel könntest du ja die Alben innerhalb der Kategorien nummeriere=
n, dann
hast du für Alben den PK (kategorie_id, album_id) und dann hat der FK v=
on
Bilder auf Alben schon die Kategorie mit drin, ohne die Normalisierung zu=

verletzen. Das hat aber möglicherweise andere Nachteile, zum Beispiel w=
enn du
URLs für eine Sicht auf ein Album erstellen willst, hast du dann immer =
zwei
Nummern rumzuschleppen.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

am Tue, dem 10.04.2007, um 17:55:10 +0200 mailte Tim Frießinger folgen=
des:
> Hallo und danke für die Antwort!

Ich erlaube mir mal, das wieder in die Liste zu leiten, okay?


> Warum probierst Du es nicht mal aus? Erzeug Dir doch mal eine zweit=
e
> Tabelle der Bilder _MIT_ diesem FK auf die Kategorie (create table
> bilder2 as select ...) und schau mit EXPLAIN ANALYSE, was da bei
> rauskommt.
>
>
> Vermutlich ist es wirklich das beste wenn ich mal ein eine Datenbank mi=
t
> Testdaten aufbaue und einfach die Geschwindigkeit vergleiche.

Jepp, und EXPLAIN ANALYSE kennst Du sicherlich schon, oder?


> Ich kenne bisher halt eben eher die Theorie, wonach man ja nach einer
> Normalisierung auf keinen Fall eine Datenredundanz haben sollte.
> Allerdings habe ich gehört, dass in der Praxis aus Performance-Grün=
den durchaus
> bewusst dagegen verstoßen wird.=A0
>
> ANALYSE erneuert ja die internen Heuristiken von PostgreSQL, mal angeno=
mmen die
> Datenbank wäre irgendwann mal im regen Betrieb, wie häufig empfiehl=
t sich denn
> dann eine Ausführung selbigen Befehls?

Ich glaube, das verwechselst Du mit VACUUM. Das schafft Platz und
kümmert sich um die Statistiken. Neuere Versionen (ab 8.x) haben fest
Autovacuum integriert, man kann da aber auch einiges optimieren.

Generell: nach heftigen =C4nderungen (INSERT/UPDATE/DELETE) ist das
sinnvoll und nötig.


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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

In article <20070411084553.GE29744-v/7JME6m4x+bVpMeMcYZ6Q [at] public.gmane.org>,
"A. Kretschmer" <andreas.kretschmer-feKy5vuD6Kt9uiUsa/gSgQ [at] public.gmane.org> writes:

>> Ich kenne bisher halt eben eher die Theorie, wonach man ja nach
>> einer Normalisierung auf keinen Fall eine Datenredundanz haben
>> sollte. Allerdings habe ich gehört, dass in der Praxis aus
>> Performance-Gründen durchaus bewusst dagegen verstoßen wird.=A0

Bis man sich ganz sicher bist, daß wirklich die Normalisierung ein
Problem darstellt, gilt die erste Regel der Optimierung: "Don't!"

>> ANALYSE erneuert ja die internen Heuristiken von PostgreSQL, mal
>> angenommen die Datenbank wäre irgendwann mal im regen Betrieb, wie
>> häufig empfiehlt sich denn dann eine Ausführung selbigen Befehls?

> Ich glaube, das verwechselst Du mit VACUUM.

Nein, tut er nicht.

> Das schafft Platz und kümmert sich um die Statistiken.

Nein - nur wenn man (sic!) VACUUM ANALYZE aufruft.

> Generell: nach heftigen =C4nderungen (INSERT/UPDATE/DELETE) ist das
> sinnvoll und nötig.

Genauer gesagt: nach heftigen UPDATEs und DELETEs braucht man VACUUM.
Nach heftigen INSERTs oder UPDATEs, die die Verteilung von
Schlüsselwerten verändern, braucht man ANALYZE.

Dank autovacuum sollte das aber kein großen Problem mehr sein.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--Apple-Mail-4-444848747
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
delsp=yes;
format=flowed

Hallo und danke für die zahlreichen Antworten! :)



Am 11.04.2007 um 16:01 schrieb Harald Fuchs:

> In article <20070411084553.GE29744 [at] a-kretschmer.de>,
> "A. Kretschmer" <andreas.kretschmer [at] schollglas.com> writes:
>
>>> Ich kenne bisher halt eben eher die Theorie, wonach man ja nach
>>> einer Normalisierung auf keinen Fall eine Datenredundanz haben
>>> sollte. Allerdings habe ich gehört, dass in der Praxis aus
>>> Performance-Gründen durchaus bewusst dagegen verstoßen wird.
>
> Bis man sich ganz sicher bist, daß wirklich die Normalisierung ein
> Problem darstellt, gilt die erste Regel der Optimierung: "Don't!"

Ich denke diesen Hinweis werde ich mir zu Herzen nehmen.
Da der Zugriff "von aussen" eh über Views realisiert ist, sollte ggf. =

eine spätere =C4nderung ja kein Problem sein.


>> Generell: nach heftigen =C4nderungen (INSERT/UPDATE/DELETE) ist das
>> sinnvoll und nötig.
>
> Genauer gesagt: nach heftigen UPDATEs und DELETEs braucht man VACUUM.
> Nach heftigen INSERTs oder UPDATEs, die die Verteilung von
> Schlüsselwerten verändern, braucht man ANALYZE.

Wie läuft das in der Praxis mit ANALYZE? Muss der Administrator immer =

regelmässig quasi "nach Augenmaß" entscheiden, wann es mal wieder =

Zeit für einen Aufruf von ANALYZE ist. oder gibt es da andere
Möglichkeiten? (Cron-Job etc...) Wenn ich selber für die INSERTS
etc... verantwortlich bin, kann ich das ja noch selber gut
entscheiden, aber wenn auf der Datenbank noch viele andere User
arbeiten (und Daten verändern), wie entscheidet man dann?

Danke & Gruß,
Tim



--Apple-Mail-4-444848747
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Hallo und danke für die =
zahlreichen Antworten! :)<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><BR><DIV><DIV>Am 11.04.2007 =
um 16:01 schrieb Harald Fuchs:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">In article <<A =
href=3D"mailto:20070411084553.GE29744 [at] a-kretschmer.de">20070 411084553.GE29=
744 [at] a-kretschmer.de</A>>,</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">"A. =
Kretschmer" <<A =
href=3D"mailto:andreas.kretschmer [at] schollglas.com">andreas.kr etschmer [at] schol=
lglas.com</A>> writes:</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Ich kenne bisher halt eben eher =
die Theorie, wonach man ja nach</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">einer =
Normalisierung auf keinen Fall eine Datenredundanz haben</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">sollte.<SPAN class=3D"Apple-converted-space">=A0 =
</SPAN>Allerdings habe ich gehört, dass in der Praxis aus</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Performance-Gründen durchaus bewusst dagegen =
verstoßen wird.=A0</DIV> </BLOCKQUOTE></BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Bis man =
sich ganz sicher bist, daß wirklich die Normalisierung ein</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Problem darstellt, gilt die erste Regel der =
Optimierung: "Don't!"</DIV></BLOCKQUOTE><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Ich denke diesen Hinweis =
werde ich mir zu Herzen nehmen.</DIV><DIV>Da der Zugriff "von aussen" eh =
über Views realisiert ist, sollte ggf. eine spätere =C4nderung ja =
kein Problem sein.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BR><BLOCKQUOTE =
type=3D"cite"><BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Generell: =
nach heftigen =C4nderungen (INSERT/UPDATE/DELETE) ist das</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">sinnvoll und nötig.</DIV> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Genauer =
gesagt: nach heftigen UPDATEs und DELETEs braucht man VACUUM.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Nach heftigen INSERTs oder UPDATEs, die die =
Verteilung von</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Schlüsselwerten verändern, =
braucht man ANALYZE.</DIV></BLOCKQUOTE></DIV><SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><SPAN =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Wie läuft das in der =
Praxis mit ANALYZE? Muss der Administrator immer regelmässig quasi =
"nach Augenmaß" entscheiden, wann es mal wieder Zeit für einen =
Aufruf von ANALYZE ist. oder gibt es da andere Möglichkeiten? =
(Cron-Job etc...) Wenn ich selber für die INSERTS etc... =
verantwortlich bin, kann ich das ja noch selber gut entscheiden, aber =
wenn auf der Datenbank noch viele andere User arbeiten (und Daten =
verändern), wie entscheidet man dann?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Danke & =
Gruß,</DIV><DIV>Tim</DIV><BR =
class=3D"Apple-interchange-newline"></SPAN></SPAN></SPAN></SPAN> =
<BR></DIV></BODY></HTML>=

--Apple-Mail-4-444848747--

Tim Frießinger wrote:
> Wie läuft das in der Praxis mit ANALYZE? Muss der Administrator immer
> =A0 regelmässig quasi "nach Augenmaß" entscheiden, wann es mal wied=
er
> Zeit für einen Aufruf von ANALYZE ist.

Es gibt ja Autovacuum, das enthält auch ein "Autoanalyze".

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate