✔ MySQL: Mehrere Selects oder einen Großen

Hi

Redundanzen, die nur da sind, weil man es nicht besser machen kann oder nicht genug mitgedacht hat,
sind schlecht (mehr Daten, langsamer, mehr Komplexität => mehr Fehler usw.usw.).
Um die gehts meistens, wenn davon abgeraten wird.

Wenn man genau weiß, was man tut, und warum genau da und dort etwas redundant sein soll: Kein Problem.
(bis auf das erhöhte Fehlerrisiko beim Codeschreiben, weil üblicherweise dadurch auch mehr Code entsteht)

Man sollte sich aber sicher sein, dass die Vorteile überwiegen, nicht automatisch DB-Daten redundant machen weil man annimmt dass es hilft (extrem negatives Beispiel: 15GB statt 5GB, um einem einzelnen Nutzer zehn Sekunden pro Monat zu sparen? Nein.)
 
Ja Eigebtlich spricht ja alles für Normalisierung aber ich bin etwas verwirrt warum die großen forenentwickler alle auf Redundanzen setzten und mein anwendungsfall ja ähnlich ist
 
Ohne zu wissen, von welchem Fall du gerade redest,
ein Beispiel wäre zB. hier die Forenübersicht mit der Anzeige des neuesten Beitrags pro Forenbereich.

Ohne Redundanz:
Für jeden Aufruf der Forenliste (inkl. Bots usw.) pro Unterforum alle Beiträge seit Jahr 2000 (!) durchgehen
und von denen den Neuesten des Unterforums raussuchen.
(Ja, gute DB-Indexe helfen, aber geht trotzdem noch viel besser).

Mit Redundanz:
Die ID vom neuesten Beitrag pro Unterforum in einer eigenen kleinen Tabelle speichern,
Für jeden Aufruf der Forenliste pro Unterforum genau einen Datensatz aus der schnell durchsuchbaren Tabelle holen,
Bei neuen Beiträgen auch die kleine Tabelle mitändern.

Neue Beiträge gibts viel weniger als Seitenaufrufe, in jedem Forum der Welt,
und das Mitändern einer zweiten Tabelle ist billig verglichen mit dem Durchsuchen aller Beiträge.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück