Die Frage spricht für sich...
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 ...
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?
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)
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.
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.
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!
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?
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 ... :-)
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.
:
Bearbeitet durch User
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.