✔ MySQL: Mehrere Selects oder einen Großen

Hallo,
für mein neues Projekt was einem Forum ähnelt bin ich auf der Suche nach einer ordentlichen Datenbankstruktur.

Ich habe mir überlegt eine Tabelle mit max. 100 Einträgen einmalig im Seitenkopf auszulesen und daraus ein Array erstellen zu lassen und über diesen die Daten zu verwerten (z.B. über rekursion)

Die Alternative wäre, ca 20 kleinere Selects auszuführen.

Meine Frage:
Was ist sinnvoller, ein großer Select, oder mehrere kleine und ist die Variante mit dem Array überhaupt performant oder gibts bessere Möglichkeiten?

Hi,

prinzipiell gilt: Je weniger Abfragen desto besser.
Das hängt aber auch noch von anderen Faktoren ab:
- Datenbanktyp (MySQL, Oracle, Microsoft etc.)
- Art der Abfragen
- Korrekte Verwendung von Indices
- Bewusste Denormalisierung
etc.

Am Besten einfach ausprobieren & messen.

Grüsse,
BK

Danke dir.

Messen einfach per Microtime am Anfang und am Ende?

Ist es eigentlich aufwändig grose arrays erstellen zu lassen oder nur wenn ich diese auch Rednern also ausgebe würde?

Hi,

grosse Arrays brauchen natürlich auch Zeit zum erstellen, vorallem wenn sie wie in PHP dynamisch wachsen. Auf alle Fälle braucht die Lösung mit einem grossen Array mehr Arbeitsspeicher als die mit den vielen kleinen Abfragen. Mit PHP Performance bin ich nicht ganz so fit, am Besten einfach mal mit grossen Datenmengen ausprobieren und Zeiten messen.

Grüsse,
BK

Wie ist es denn mit joins? Ist es performanter auf eine andere dB zu joinen als nen zweiten select zu schreiben?

Hi,

Joins sind performanter als Kreuzprodukte (SELECT * FROM table1, table2, table3 WHERE ....), aber wie das bei Joins zwischen mehreren Datenbank aussieht: Ausprobieren.

Grüsse,
BK

Vielen Dank nochmal ich konnte schon viel optimieren allerdings bleibt noch eine Frage offen:

Ich müsste Daten aus bis zu vier Tabellen holen, was ja mit selects oder wie ich jetzt gelernt habe auch ganz gut mit joins funktioniert.

Derzeit sind diese Daten redundant in je zwei Tabellen gespeichert was mir das Abfragen mit nur einem selects ermöglicht.

Beim schreiben und ändern müssen dann natürlich beide Tabellen geändert werden.

Lesen kommt aber wesentlich häufiger als schreiben oder Updates vor, desshalb meine Frage:

Sollte ich es eher mit joins lösen da die nicht so sehr ins Gewicht fallen???oder soll ich es redundant lassen wie es jetzt ist.

Danke

Hi ThiKool,

das kommt ganz darauf an, was das für Daten sind.
Würdest du einen Lehrer, Dozent, Prüfer, etc. fragen wäre die Antwort mit Sicherheit: Normalformen beachten, keine redundanten Daten, dass ist sonst schlechtes Design, arbeite lieber mit Joins.

Lass dir aber aus der Praxis folgendes gesagt sein:
Wenn es sich um Daten handelt, die nur schwer verjoinbar sind ODER wo der Join sehr, sehr lange braucht, aber sehr viele SELECTS drauf gehen -> Lass die Daten redundant. Das wird u.a. eben deswegen gemacht, weil die Joins einfach sehr lange brauchen können und wenn du wie gesagt viele Lesende, aber nur wenige Schreibende Zugriffe hast, dann ist das auch kein schlechtes DB-Design, sondern einfach Optimierung in Sachen Performance. (Auch wenn du in einer Prüfung damit wahrscheinlich keine Punkte ernten würdest...wiedermal ein Beweis dafür, dass Theorie oft ungleich Praxis).

Damit beide Tabellen bei einem Insert oder Update auf einer von beiden aktualisiert werden, kannst du Trigger verwenden.
(https://dev.mysql.com/doc/refman/5.0/en/trigger-syntax.html)

Wenn du Fragen dazu hast, dann einfach rein ins Forum, ist ja kein Hexenwerk, da kennen sich hier sicher viele mit aus und können dir dann auch helfen


Gruß
Daniel

Danke Daniel, dass hat mir sehr weitergeholfen. Wenn das mit triggern so klappt (werd ich mir noch ansehen) dann werd ich es wohl redundant lassen. Danke nochmal

Ich muss mich nochmal an euch wenden. Nahezu überall wird davon gesprochen Redundanzen zu vermeiden. Allerdings hab ich mir verschiedene forensoftware (burning board usw) angesehen und dort wird ja eben auch bewusst redundant gespeichert.

Mein Projekt ist einem Forum ziemlich ähnlich desshalb weis ich nicht was ich jetzt machen soll.