MySQL - Perfomance Frage - Verknüpfte Tabellen

[naitsab]

Abend,

meine Situation ist die Folgende (Es geht um eine Bilder-Galerie):

Ich habe eine MySQL-Tabelle mit 10 Feldern (Name der Galerie, Beschreibungs-Text, etc..)

Pro Galerie sollen 8 Bilder vorhanden sein.
Dabei stellt sich mir folgende Frage und mir geht es dabei nur um die MySQL-Auslastung, da später sehr viele Galerien und Aufrufe vorhanden sein werden.

Sollte ich eine extra Tabelle erstellen, in der ich jedes Bild einzeln eintrage und mit der Galerie-ID verknüpfe? (ID, ID_Galerie, BILDURL).

ODER

sollte ich die Bilder mit Semikolon getrennt in ein Feld in die Galerie-Tabelle dazustecken.
Das Feld würde dann inhaltlich so aussehen: bild1.jpg;bild2.jpg;bild3.jpg;etc...

Programmierungstechnisch ist für mich beides kein Problem, habe auch schon beide Varianten ausprobiert, mir geht es wie gesagt nur um die MySQL-Server-Auslastung bei dem ganzen. Mir ist es schnurz egal, ob ich jetzt in der 3. Normalform bin oder nicht. Übersichtlichkeit ist auch egal.

Ich sehe bei der Semikolon-Variante den Vorteil, dass ich mir ja immer ein Query spare, weil ich mir ja nicht mehr mit der Galerie-ID das jeweilige Bild raussuchen muss.
Allerdings werden bei der Semikolon-Variante auch immer alle Bilder aus der Datenbank ausgelesen und das Datenvolumen ist größer.

Also geht Query-Anzahl gegen Datenvolumen, sehe ich das richtig oder habe ich da einen Denkfehler.

Was meint ihr dazu?

Wäre schön, wenn ich mal verschiedene Meinungen von Fachmännern dazu höre, weil ich selber erst ein fortgeschrittener Anfänger bin.

*edit*: Habe noch vergessen zu erwähnen, dass es später mal weit über 10.000 Bilder sein werden. Das könnte ja für ne Beurteilung von Relevanz sein.

[ghostgambler]

Halte deine Tabelle entsprechend den Normalformen.
Wenn das später an der Performance suckt, dann kannst du wieder kommen.

[PHP-Desaster]

Schon alleine weil du so viele Bilder hast, würde ich sie einzeln abspeichern. Die Normalformen sind ja nicht ohne Sinn eingeführt worden. Wie ghostgambler schon sagt, wenn du mit der Normalform feststellst, dass dir Performance fehlt, kann man über Optimierungen nachdenken! Meist ist es aber eh so, das ein zweiter Server günstiger wäre als ein Umbau des Quellcodes

[naitsab]

wenn ich später bei 10.000 Bildern Perfomance Einbüßungen habe, kann ich ja wohl schlecht auf das andere System umsteigen.
Bis das alles umgeschrieben ist, vergehen ja Jahre.

Deswegen wollte ich das ja vorher abgeklärt haben.
Es heißt ja immer, man soll die Normalformen verwenden, aber Gründe habt ihr mir auch keine genannt

[ghostgambler]

Was hat die Anzahl der Bilder mit dem Umschreiben des PHP-Codes zutun?
Was machst du, wenn du das System später erweitern willst, dafür die Einhaltung einer Normalform brauchst, die Daten aber nur denormalisiert vorhanden sind? Es ist unlustig Gigabyte große Tabellen zu normalisieren...

[naitsab]

Ich hab ja nicht vom Umschreiben des PHP-Codes gesprochen, sondern eben genau von der Umwandlung der Datenbank-Tabelle.
Aber halt in die andere Richtung, von Normal zu Einer Tabelle.

[ghostgambler]

Es ist deutlich einfacher einen zusätzlichen Cache zu bauen, als aus einem Cache die originalen Daten zu erhalten.

[naitsab]

ok, überzeugt, ich mach's jetzt mit der 3. Normalform.
Ihr habt schon recht, später werd ichs gebrauchen können.

Aber dazu wollte ich immer schon was fragen. Was ist denn der Unterschied zwischen:

SELECT
t1.zahl, t2.quadrat
FROM
tabelle1 t1
INNER JOIN tabelle2 t2 USING(tab1_id)

und

SELECT
t1.zahl, t2.quadrat
FROM
tabelle1 t1, tabelle2 t2
WHERE
t1.tab1_id=t2.tab1_id


Datenbankstruktur wie oben im JOINS sticky thread.

Das Ergebnis sollte ja dasselbe sein. Hat die JOINS Variante Perfomance Vorteile?

[ghostgambler]

Nein, die sind beide vollständig äquivalent, aber zugunsten der Leserlichkeit bevorzuge ich die Variante mit "INNER JOIN", statt einfach nur eine per Komma separierte Liste...

Und spätestens, wenn man dann mehrere Tabellen über verschiedene JOIN-Arten verknüpfen will, alternativ noch ausgeklügelte ON mit WHERE-Klauseln verbinden will, kommt man um die längere, aber meiner Meinung nach halt deutlichere, Variante, sowieso nicht mehr drumherum.

[tontechniker]

Hat die JOINS Variante Perfomance Vorteile?

Ja, anfangs nur marginal, wenn du allerdings viele Ergebnisse und große Felder hast lohnt es sich schon - ein Beispiel:

[i]// Database Querys / Querytypes	(10000x)
[u]//Normal                  | 15 Spalten             | 15 Spalten + 1 Feld mit ~5000 Zeichen[/u]
//Zeit: 2.89275288582 sec | Zeit: 4.5441839695 sec | Zeit: 16.4118978977 sec[/i]
[COLOR=darkblue]SELECT * FROM posts p, comments c WHERE p.id = c.post_id AND p.id = 1[/COLOR]
[i]//Zeit: 2.82277488708 sec | Zeit: 4.5260310173 sec | Zeit: 16.2775440216 sec[/i]
[COLOR=darkblue]SELECT * FROM posts p JOIN comments c ON p.id = c.post_id WHERE p.id = 1[/COLOR]

[ghostgambler]

Optimiert der Optimizer sowas nicht?...

[naitsab]

oh, dann werde ich mir mal angewöhnen mit JOIN zu arbeiten.

danke euch beiden.


aber grundsätzlich gilt also, wenn ich das richtig verstanden habe:
alles, was man mit JOIN macht, könnte man auch mit WHERE lösen?

[ghostgambler]

Original geschrieben von naitsab
aber grundsätzlich gilt also, wenn ich das richtig verstanden habe:
alles, was man mit JOIN macht, könnte man auch mit WHERE lösen?

Ne, glaube nicht, zumindest wüsste ich spontan nicht, wie man so einen LEFT JOIN nachbauen könnte.

[tontechniker]

Optimiert der Optimizer sowas nicht?...

Größtenteils schon denk ich - aber die Zeitmessung sagt was anderes. Kommt insgesamt natürlich auch auf Indizes und Datenmengen an.