[MySQL] Viele Datensätze verwalten

[wesker_re]

[MySQL] Viele Datensätze verwalten

Hallo,

ich code zur Zeit eine kleine Seite die es dem Besucher ermöglichen soll seine Sammlung von Videospielen / Konsolen online zu verwalten - sprich Spiele eintragen, editieren und löschen. Das ganze geschieht über eine Benutzerverwaltung (Besucher kann sich registrieren und dann einloggen und beginnen).

Die Seite ist erstmal für die Besucher unseres Forum gedacht, da sich darunter viele Sammler befinden. Nun mal langsam zu meiner Frage: Da diese Leute teilweise sehr grosse Sammlung haben (1000-2000 Spiele und mehr) frage ich mich nun wie ich diese Datensätze verwalte. Sollte ich für jeden User eine eigene Tabelle erstellen lassen, in der dann die Spiele nur von dieser Person reinkommen oder einfach nur eine Tabelle für alle User?

Gibt es da große Unterschiede bei der Performance? Welche Vorteile / Nachteile haben beide Methoden?

Schonmal Danke für eure Hilfe!

Bis die Tage...
wesker_re

 

[ZAM]

AW: [MySQL] Viele Datensätze verwalten

Da ich zu müde bin um konstruktiv eine saubere Struktur anzubieten bin ich einfach mal gespannt was hier wieder für Hobbyangebote von Datenbankstrukturen kommen *g*
Au Au nicht haun.

Btw. Einzelne Tabellen für jeden Benutzer wäre nicht sehr sinnvoll. Verwaltungstechnisch schonmal garnicht.

Spoiler

Wäre aber genau der richtige Thread für Markus auch wenn es sich um MySQL handelt statt Postgres.

 

[Markus_Wollny]

AW: [MySQL] Viele Datensätze verwalten

Hallo,

ich code zur Zeit eine kleine Seite die es dem Besucher ermöglichen soll seine Sammlung von Videospielen / Konsolen online zu verwalten - sprich Spiele eintragen, editieren und löschen. Das ganze geschieht über eine Benutzerverwaltung (Besucher kann sich registrieren und dann einloggen und beginnen).

Die Seite ist erstmal für die Besucher unseres Forum gedacht, da sich darunter viele Sammler befinden. Nun mal langsam zu meiner Frage: Da diese Leute teilweise sehr grosse Sammlung haben (1000-2000 Spiele und mehr) frage ich mich nun wie ich diese Datensätze verwalte. Sollte ich für jeden User eine eigene Tabelle erstellen lassen, in der dann die Spiele nur von dieser Person reinkommen oder einfach nur eine Tabelle für alle User?

Gibt es da große Unterschiede bei der Performance? Welche Vorteile / Nachteile haben beide Methoden?

Schonmal Danke für eure Hilfe!

Bis die Tage...
wesker_re

Grundsätzlich wäre es sinnvoller, auf eine zu starke Verteilung in viele Tabellen zu verzichten - spätestens wenn Du Abfragen hast, die z.B. ermitteln sollen, in wie vielen Userprofilen ein bestimmtes Spiel enthalten ist, bekommst Du mit so einer Struktur Schwierigkeiten.

Sinnvoller ist die übliche Dreiteilung: Eine Usertabelle (user_id, Login, ...), eine Spieletabelle (game_id, evtl. alt_game_id, status, Name, ...) und eine Zuordnungstabelle (user_id, game_id), Indizes jeweils auf die ID-Felder.

Du solltest dann in Deiner Applikation dafür sorgen, dass die User ein Spiel aus der Liste der vorhandenen wählen und, sofern das Spiel noch nicht in der Liste ist, ein neues Spiel anlegen. Du als Admin solltest dann regelmäßig einen Blick auf die neu hinzugefügten Spiele werfen, deren Statuswert anpassen (z.B. 1=neu angelegt, 10=verifiziert, -1=gesperrt, 5=Umleitung gesetzt) und bei Doubletten alt_game_id auf die game_id des ersten betreffenden Eintrags setzen - dadurch kannst Du dann automatisch alle Zuordnungen ändern und anschließend die Doublette rauswerfen.

Mit entsprechenden Join-Abfragen kannst Du damit dann nicht nur die userbasierten "Spielebibliotheken" anzeigen, sondern noch viele weitere spaßige Sachen veranstalten, z.B. Spiele-Top-10 oder Hersteller-Top-10 oder die User mit den größten Bibiotheken usw.

 

[marky68]

AW: [MySQL] Viele Datensätze verwalten

ergaenzung: beschaeftige dich mal mit normalformen

 

[wesker_re]

AW: [MySQL] Viele Datensätze verwalten

@Markus Wollny:
Erstmal Danke für diese tolle Erklärung.

Es ist also nicht sinnvoll eine Tabelle "Spiele" anzulegen und die Einträge per UserID den Besitzern zuzuordnen? Also ohne eine globale Spieleliste aus der man dann wählen kann und diese selbst mitgestaltet. Weil wer garantiert mir dass jeder erstmal in der Liste nachsieht (zumal diese Liste ja bei 0 angefangen werden müsste, da ich auf keine vorhandene Datenbank zurückgreifen kann) oder ein Spiel nicht zum dritten Mal erstellt, nur weil er es vielleicht ein wenig anders schreibt. (Star Wars - Knights Of The Old Republic <-> Star Wars KOTOR als Beispiel)

Da müsste ich ja ständig kontrollieren und korrigieren. Dafür hab ich ehrlich gesagt nicht die Zeit (und auch nicht die Lust)

Andereseits würde nach meiner Methode das Spiel "Half Life" bei 100 Usern vielleicht 80 mal drinstehen - eben weil es soviele haben.

Hmm, jetzt bin ich erstmal ratlos...

Bis die Tage...
wesker_re

 

[soulsaver]

AW: [MySQL] Viele Datensätze verwalten

Sinnvoll wäre es sicherlich die Spiele in Genres zu unterteilen. Das wäre der erste FIlter. Dann vielleicht noch nach Anzahl der möglichen Spielern und Altersbegrenzung etc. um es somit dem User, der sein Spiel eintragen möchte, deutlich zu vereinfach. Somit hat er eher Lust sein Spiel inder vorhandenen Liste zu suchen da er differenzieren kann.

edit: Differenzieren nach der Plattform


Was sicherlich noch dazu sehr sinnvoll wär ist eine Spielesuchmaschine. Der user kann ja lediglich Star Wars eingeben und es kommen 10 Spiele aus denen er seins heraussuchen kann.

Wie auch immer du das lösen möchtest, es wird dir ne Menge Arbeit abverlangen aber ich kann dich nur motivieren dranzubleiben. Wenn du das geschafft hast, bist du ganz bestimmt um einiges fitter als vorher im Umgang mit Datenbanken etc.

 

[Markus_Wollny]

AW: [MySQL] Viele Datensätze verwalten

@Markus Wollny:
Erstmal Danke für diese tolle Erklärung.

Es ist also nicht sinnvoll eine Tabelle "Spiele" anzulegen und die Einträge per UserID den Besitzern zuzuordnen? Also ohne eine globale Spieleliste aus der man dann wählen kann und diese selbst mitgestaltet. Weil wer garantiert mir dass jeder erstmal in der Liste nachsieht (zumal diese Liste ja bei 0 angefangen werden müsste, da ich auf keine vorhandene Datenbank zurückgreifen kann) oder ein Spiel nicht zum dritten Mal erstellt, nur weil er es vielleicht ein wenig anders schreibt. (Star Wars - Knights Of The Old Republic <-> Star Wars KOTOR als Beispiel)

Da müsste ich ja ständig kontrollieren und korrigieren. Dafür hab ich ehrlich gesagt nicht die Zeit (und auch nicht die Lust)

Andereseits würde nach meiner Methode das Spiel "Half Life" bei 100 Usern vielleicht 80 mal drinstehen - eben weil es soviele haben.

Hmm, jetzt bin ich erstmal ratlos...

Bis die Tage...
wesker_re

Das Problem bei einer völlig freien Eingabe ohne eine globale Spieleliste besteht zum einen darin, dass User selten in der Lage sind, sich auf eine, geschweige denn auf die korrekte Schreibweise zu einigen. Im genannten Beispiel hättest Du dann recht schnell die Spiele Half-Life, Half Life, Halflife, HalfLif, und diverse andere Varianten, die sich allenfalls noch theoretisch mit hohem Aufwand in einer Abfrage zusammenführen lassen - praktisch sind dem Grenzen gesetzt, da die Variationen bei verschiedenen Spielen in völlig verschiedene Richtungen gehen werden (vgl. Driver 3 <-> Driv3r, Grand Theft Auto: San Andreas <-> GTA 4 usw.). Dein Vorschlag, dem User generell die freie Eingabe zu erlauben, würde diesen Umstand also stark verschärfen.

Das Problem, wie Du den Nutzer dazu bringst, zunächst ein Spiel aus der Liste auszuwählen, bevor er selbst ein neues eingibt, lässt sich am ehesten durch geschickte Benutzerführung lösen. Dazu bietest Du eben diese Freitexteingabe im ersten Schritt nicht an, sondern eben zunächst nur die Liste. Erst wenn der User z.B. zum letzten Eintrag der Liste gescrollt hat, aktivierst Du das Feld für die Eingabe eines neuen Spiels. Wichtig wäre zudem, dass Du den Usern schon zum Start eine hinreichend gut bestückte Liste anbietest und nicht vollkommen leer startest.

Letzten Endes bietet die Verknüpfung von Spiele über Int-IDs (zumindest in der Theorie) auch Performance-Vorteile gegenüber alphanumerischen Schlüsseln. Auch das spricht für eine Lösung über eine Verknüpfungstabelle, die lediglich IDs einander zuordnet. Zum einen sind numerische Indizes je nach Datenbanksystem mehr oder wenigstens gleich performant wie alphanumerische, zum anderen ist die Breite der Zuordnungstabelle wesentlich geringer als bei alphanumerischen Schlüsseln - dadurch ist ein sog. sequentieller Scan (also eine direkte Suche über die Tabelle ohne Verwendung von Indizes) deutlich schneller, da die Datenmenge pro Tupel schlichtweg geringer ausfällt.

Schließlich obliegt es Dir als Verwalter der Datenbank, den Signal-Rauschabstand der enthaltenen Informationen möglichst gering zu halten - und das bedeutet hier nun einmal, dass die eigentlichen Sinn-Inhalte kontrolliert werden müssen. Diese Arbeit sollte sich jedoch nach einem anfänglichen Run ziemlich in Grenzen halten, schließlich kommen pro Monat nicht gerade tausende neuer Spiele heraus. Wenn Du Dein "Admin-Interface" entsprechend komfortabel gestaltest, ist das Kontrollieren und ggf. Umleiten der neu hinzugekommen Einträge eine Sache von wenigen Minuten pro Woche. Sobald Du userdefinierte Informationen strukturiert organisieren möchtest (also anders als simple Prosa in z.B. Forenpostings), kommst Du um so einen Schritt letztendlich nicht herum, denn wenn Du es zulässt, dass sich in Deinem System im Laufe der Zeit erst einmal genug "Müll" angesammelt hat, verliert damit die gesamte Datenbank deutlich an Informationswert.

 

[Markus_Wollny]

AW: [MySQL] Viele Datensätze verwalten

Schließlich obliegt es Dir als Verwalter der Datenbank, den Signal-Rauschabstand der enthaltenen Informationen möglichst gering zu halten - und das bedeutet hier nun einmal, dass die eigentlichen Sinn-Inhalte kontrolliert werden müssen. Diese Arbeit sollte sich jedoch nach einem anfänglichen Run ziemlich in Grenzen halten, schließlich kommen pro Monat nicht gerade tausende neuer Spiele heraus. Wenn Du Dein "Admin-Interface" entsprechend komfortabel gestaltest, ist das Kontrollieren und ggf. Umleiten der neu hinzugekommen Einträge eine Sache von wenigen Minuten pro Woche. Sobald Du userdefinierte Informationen strukturiert organisieren möchtest (also anders als simple Prosa in z.B. Forenpostings), kommst Du um so einen Schritt letztendlich nicht herum, denn wenn Du es zulässt, dass sich in Deinem System im Laufe der Zeit erst einmal genug "Müll" angesammelt hat, verliert damit die gesamte Datenbank deutlich an Informationswert.

Ergänzung: Du kannst Dir auch einen Weg überlegen, wie Du nach dem Wiki-Prinzip auch diese Kontrollarbeit auf die User überträgst; hierfür musst Du lediglich alle Änderungen historisieren, so dass auch ein partieller Rollback von Änderungen auf einen früheren Zustand möglich wird. Das setzt jedoch trotzdem ein Mindestmaß an Disziplin bei Deinen Usern voraus; ist das nicht generell vorhanden, kannst Du so etwas vielleicht über User-Ränge mit unterschiedlichen Berechtigungen angehen. Es spricht allerdings auch nichts dagegen, das System zunächst "simpel" zu starten und solche Dinge erst später als Erweiterungen zu realisieren.

 

[wesker_re]

AW: [MySQL] Viele Datensätze verwalten

Hab mir jetzt länger Gedanken über dein Geschriebenes gemacht und muss gestehen dass es sich immer sinnvoller anhört. So versteh ich das auch was du meinst, nur eine Frage stellt sich mir immer noch. Wenn ich in einer Tabelle immer nur die Verknüpfungen UserID und GameID speichere (so meintest du das doch, oder?) und dann eine Spielesammlung ausgeben möchte, muss ich dann nicht immer beiden Tabellen abfragen (die erste um an die ID des Spiels zu kommen und dann die zweite für die Ausgabe)? Geht das nicht zu Lasten der Performance? (Oder meintest du das überhaupt so?)

Sorry wenn die Frage(n) dumm ist / sind, aber ich bin nicht so der MySQL Experte. Die einfachen Sachen wie normale Abfragen, Änderungen usw kapier ich ja, aber bei Überlegungen der Performance usw muss ich dann doch kapitulieren. Andererseits möchte ich es aber von Anfang an sauber und struktuiert angehen - um nicht hinterher die doppelte Arbeit zu haben.

Aber auf jeden Fall nochmal ein großes Dankeschön, mit deinen bisherigen Tipps hast du mir schon sehr geholfen.

Das mit der Benutzerführung hatte ich mir heute auch schon selbst überlegt und da bin ich zum gleichen Ergebnis gekommen.

Bis die Tage....
wesker_re

 

[Markus_Wollny]

AW: [MySQL] Viele Datensätze verwalten

Hab mir jetzt länger Gedanken über dein Geschriebenes gemacht und muss gestehen dass es sich immer sinnvoller anhört. So versteh ich das auch was du meinst, nur eine Frage stellt sich mir immer noch. Wenn ich in einer Tabelle immer nur die Verknüpfungen UserID und GameID speichere (so meintest du das doch, oder?) und dann eine Spielesammlung ausgeben möchte, muss ich dann nicht immer beiden Tabellen abfragen (die erste um an die ID des Spiels zu kommen und dann die zweite für die Ausgabe)? Geht das nicht zu Lasten der Performance? (Oder meintest du das überhaupt so?)

Naja, Relationen sind ja der Grund, wozu man eben relationale Datenbanken verwendet *g*

DIe Antwort auf Deine Frage ist also eindeutig Jein. Es kommt auf die Art des Zugriffs und die vorliegenden Daten an. Zunächst sollten allerdings zumindest der "reinen Lehre" zufolge Redundanzen vermieden werden (weiter oben im Thread hat jemand ja schon die Normalformen erwähnt). Dadurch erreichst Du zunächst einmal maximale Flexibilität und Struktur. Die Zuordnungstabelle ist zudem zwar lang, dafür aber sehr schmal, so dass das eigentlich aufwändige, die Abfragen nach der Zuordnung, doch sehr schnell vonstatten gehen kann. Das Zusammensammeln der Daten nach einem Primärschlüssel fällt in vielen Szenarien weniger ins Gewicht.

Du kannst, wenn du den Daten einmal ein sauberes Modell gegeben hast, auch für spezielle Abfragefälle optimierte Tabellen anlegen, in denen die Suchergebnisse bereits mehr oder weniger fertig vorliegen - bei MySQL kenne ich mich, wie ZAM angedeutet hat, nicht sonderlich gut aus, bei PostgreSQL gibt's da ein paar Maßnahmen, die die Performance steigern können, so z.B. Prepared Statements und sog. Materialized Views (in PostgreSQL über Trigger zu realisieren).

Ich würde sagen, Google ist Dein Freund was die tatsächliche Umsetzung angeht, ich vermute jedoch einfach mal, dass Dein Projekt erst einmal noch so klein ist, dass solche Tricks hier eher wenig bringen - verteil besser erst einmal ein paar schöne Indizes auf die richtigen Felder (und nur die), dann klappt's auch mit der Performance