Ab wievielen SPalten wird eine mysql tabelle lahm?

[Emi (Gast)]

Die Frage spricht für sich...

[Troll (Gast)]

421337

[TestX .. (xaos)]

Es gibt da keinen pauschalen Wert für...bei richtiger Engine+Config+DB 
Design sind auch 1k Spalten kein Problem...der Fehler liegt eigtl immer 
beim Anwender...

Beschreib doch mal dein Problem genauer ...

[A. B. (funky)]

ohne den genauen Hintergrund zu kennen, könnte das ein Anzeichen für 
schlechtes DB Design sein, wenn man soviele Spalten benötigt, das man 
Angst hat die Performance könnte drunter leiden.
Anderseits stellt sich die Frage, wieso es schneller sein sollte, wenn 
du vieel Zeilen hast?

[jonas biensack (Gast)]

42

[Emi (Gast)]

Ich erstelle für jeden Benutzer ein Profil wo halt die 
Unterschiedlichsten Informationen gespeichert werden. Da der User aber 
auch verschiedene Sachen auf der Webseite machen kann, kann es auch sein 
dass diese Sachen zwischengespeichert werden um beim anmelden diesen 
Wert beizubehalten. (Ähnlich wie bei einem Spielstand)

[Peter II (Gast)]

Emi schrieb:
> Ich erstelle für jeden Benutzer ein Profil wo halt die
> Unterschiedlichsten Informationen gespeichert werden. Da der User aber
> auch verschiedene Sachen auf der Webseite machen kann, kann es auch sein
> dass diese Sachen zwischengespeichert werden um beim anmelden diesen
> Wert beizubehalten. (Ähnlich wie bei einem Spielstand)

dann überlege mal ob es nicht einfacher ist das als Zeilen abzulegen. 
Spalten haben den Nachteil das man beim Hinzufügen von neuen Werten die 
Struktur der Datenbank ändern muss. Eine Zeile ist einfach hinzugefügt, 
eine Spalte nicht.

[doedel (Gast)]

da hatte funky schon Recht ... schlechtes Datenmodell :-)

Mach zuerst eine Tabelle tblParameter mit den Feldern ParameterID (int, 
autoincrement) und ParameterType. Da schreibst Du alle möglichen 
Parameter rein, die Du speichern willst (was Du jetzt spaltenweise 
versuchst).

Dann eine zweite Tabelle tblParameterWert mit UserID , ParameterID und 
ParameterValue. Die beiden verknüpfst Du über ParameterID und schreibst 
für jeden Wert, den Du speichern willst einen Eintrag da rein.

Im Idealfall ist UserID übrigens auch ein INT Wert. PrimaryKey auf 
UserID + ParameterID und zusätzlich noch ein Index auf UserID alleine. 
Dann sollte das super performant sein und bietet die Flexibilität, 
zusätzlich Werte ohne Änderung am Datenmodell zu verarbeiten.

Wenn Du es noch etwas eleganter machen willst, kannst Du in tblParameter 
z. B. auch noch den Datentyp und ähnliches speichern, um die 
eingegebenen Werte automatisch zu validieren und ggf. bei der Anzeige 
korrekt zu konvertieren.

[Emi (Gast)]

Werd mir dann überlegen wie ich es wirklich mache. Werde aber 
wahrscheinlich eher diese Tabelle mal so lassen und für zukünftige 
Einträge oder Infos die dazukommen eben eine neue Tabelle mit einer 
besseren Struktur erstellen.

Aber danke für die Detailreichen Infos!

[Kaj (Gast)]

Emi schrieb:
> Werd mir dann überlegen wie ich es wirklich mache.
Hast du schon mal was von "ERM" und "normalisierung bis zur 3. 
Normalform" gehoert?

[Pete K. (pete77)]

Lahm wird eine DB meist, wenn man einen Full-Table-Scan beid er Suche 
nach der richtigen Zeile durchführt. Dann muss die DB die gesamte 
Tabelle durchsuchen (Komplexität N, z.B. 1000 Einträge = 1000s).

Mit einem Index wird es schon besser, Komplexität log N (im Beispiel 
3s).

Wenn erst einmal die richtige Zeile gefunden ist, dann ist das Holen der 
Spalteninformationen das geringste Problem.

Schau Dir mal die Definitionen von primary key, secondary key und 
Normalform an. Manchmal hilft es , sich ein fremdes ER-Modell 
anzuschauen.

Und jetzt ab mit den unbekannten Wörtern in die Suchmaschine ... :-)

[Udo S. (urschmitt)]

Statt unzähligen Spalten ist es oft besser ein abhängige (0:n) Tabelle 
mit Schlüsel-Wert Paaren aufzubauen.
und wie Pete gesagt hat die richtigen Indexe erstellen.
Ich kenne jetzt MySql nicht, aber oft hat man bei dem DBMS Tools dabei 
die einen Ausführungsplan für die gewünschte Query zeigen, anhand dessen 
man sehen kann ob ein effizienter Indexzugriff erfolgt oder evt ein 
Tablescan gemacht werden muss. Tablescans sollte man für Tabellen mit 
mehr als ein paar duzend Einträgen tunlich vermeiden.

[it depends... (Gast)]

Es kommt auch drauf an, was in den Spalten drinsteht (d.h. wie groß die 
Spalten sind).

Wie oben schon gesagt, Fullscans sind teuer, teurer bei großen Zeilen.
Also mach einen tollen Index, damit du das nie brauchst.

Wenn du varchars, varbinarys etc. hast liegt das eh nicht in der Zeile 
selbst und muss extra geladen werden.

Aus Performancegründen muss es nicht schlechter sein, alle Settings in 
einem Blob zu speichern.