Lieber mehrere Tabellen oder viele Spalten?

Hallo zusammen :)

Ich betreibe ein Browsergame (das werde ich hier jetzt nicht nennen^^).
Serverseitig gibt es in diesem Spiel eine Tabelle für die Benutzer. Die Spalten dieser Tabelle steigen immer mehr, da ich immer mehr Funktionen und Speicherwerte pro Benutzer brauche.

Ganz einfache Frage: Soll ich das lieber irgendwann auf zwei Tabellen aufteilen? Oder in einer lassen?

Momentan beträgt die Anzahl der Spalten 80. Das Spiel läuft wunderbar (aus meiner Sicht); ich weiß allerdings nicht, ob es noch schneller ginge ;)

Falls noch irgendwelche Informationen benötigt werden, werde ich diese gerne nennen!

Gruß und in Hoffnung auf Hilfe :)

Phaltôn

[Crisps]

Eine Normalisierung der Tabellen ist vorzuziehen und kann die Performance verbessern. Zeig doch mal die "CREATE TABLE..." deiner jetzigen Tabellen und einen typischen Dateneintrag, vielleicht kann man dann mehr dazu sagen.

*Edit: Ich glaub ich hab dich falsch verstanden. Wenn es keinen guten Grund (wie z.B. Normalisierung) gibt, dann ist es nicht nötig eine Tabelle einfach so aufzuteilen. Du kannst deine User Tabelle also ruhig 'in einem Stück' lassen. :D

Den Begriff Normalisierung musste ich erst mal nachschlagen, kannte ich nich ^^
Bin aber zum Schluss gekommen, dass das nicht so gaaanz das ist, was ich wollte :D

Das heßt, selbst wenn jetzt noch 70 Spalten dazukommen, soll ich lieber bei einer Tabelle bleiben? Das kann nämlich gut passieren...
Dennoch würde ich so ziemlich alle Einträge brauchen und müsste sonst an manchen stellen lästige JOINs oder zusätzliche Abfragen machen... Auch nicht optimal...

Den CreateTable-Befehl kann ich nicht ohne weiteres hier posten. Könnte ihn dir höchstens per PN schicken oder mit anderen Spaltentiteln...

[Crisps]

Wenn Du sowieso immer alle Spalten brauchst, wäre es unnötig die Tabelle einfach so grundlos zu trennen. MySQL selbst hat ja ein Limit von 3398 möglichen Spalten, also sollte das technisch gesehen kein Problem sein - auch wenn das natürlich nicht sehr übersichtlich ist.

Was man allerdings unbedingt vermeiden sollte wäre ein solches Design:

freund1_id | freund2_id | freund3_id | ... etc.

Den CreateTable-Befehl kann ich nicht ohne weiteres hier posten. Könnte ihn dir höchstens per PN schicken oder mit anderen Spaltentiteln...

Höchst mysteriös :D
Ok, wenn du trotzdem willst, dass ich mir das mal anschaue, kannst du es ja per PM schicken.

[cortex]

die performance ist grösser, wenn du die daten auf mehrere tabellen verteilst. das wird besonders deutlich, wenn du dir überlegst, was innerhalb der db bei lese- und schreibzugriffen passiert; stichwort table locking:

http://dev.mysql.com/doc/refman/6.0/...ng-issues.html

du hast bereits jetzt 80 spalten in deiner benutzer-tabelle...? das riecht nach schlechtem db-design. mach dir mal ein paar gedanken, welche daten tatsächlich user-spezifisch sind (username, pwd, email etc.) und welche daten lediglich durch eine fremdbeziehung mit einem user in verbindung gebracht werden (spielstände, logs, settings etc.).

normaliserung war ja bereits ein hinweis; wenn du damit nicht vertraut bist, wird's höchste zeit .-

http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

cx

[feuervogel]

Zitat von Phaltôn

Den CreateTable-Befehl kann ich nicht ohne weiteres hier posten. Könnte ihn dir höchstens per PN schicken oder mit anderen Spaltentiteln...

und wieso nicht? wenn du dein wissen für dich behälst (warum auch immer), behalte ich mein wissen auch vorerst für mich.

Umfassende Antwort folgt ^^

Zitat von Crisps

Wenn Du sowieso immer alle Spalten brauchst, wäre es unnötig die Tabelle einfach so grundlos zu trennen. MySQL selbst hat ja ein Limit von 3398 möglichen Spalten, also sollte das technisch gesehen kein Problem sein - auch wenn das natürlich nicht sehr übersichtlich ist.

Das ist schon mal gut...Wichtig wäre neben den Limits natürlich auch die Performance :)

Zitat von Crisps

Was man allerdings unbedingt vermeiden sollte wäre ein solches Design:

freund1_id | freund2_id | freund3_id | ... etc.

In der Tat, stattdessen habe ich z.B. entweder 1. nen String mit | geteilt genommen oder 2. eine neue Tabelle gemacht ;)

Zitat von Crisps

Höchst mysteriös :D
Ok, wenn du trotzdem willst, dass ich mir das mal anschaue, kannst du es ja per PM schicken.

Mach ich gerne. Wollte das nur nicht hier so offen rumposten...

Zitat von cortex

die performance ist grösser, wenn du die daten auf mehrere tabellen verteilst. das wird besonders deutlich, wenn du dir überlegst, was innerhalb der db bei lese- und schreibzugriffen passiert; stichwort table locking:

http://dev.mysql.com/doc/refman/6.0/...ng-issues.html

Schau ich mir mal an und überleg ich mir mal...
Trotzdem ist mir ganz deutlich aufgefallen: Jede neue Abfrage aus PHP braucht erst mal eine Grundzeit. Das heißt: Mit jeder neuen Abfrage steigt zwingend die Ladezeit - je größer die Tabelle bzw. je größer die Datenmengen, desto mehr Zeit wird gebraucht (ist so meine Erfahrung).

Zitat von cortex

du hast bereits jetzt 80 spalten in deiner benutzer-tabelle...? das riecht nach schlechtem db-design. mach dir mal ein paar gedanken, welche daten tatsächlich user-spezifisch sind (username, pwd, email etc.) und welche daten lediglich durch eine fremdbeziehung mit einem user in verbindung gebracht werden (spielstände, logs, settings etc.).

Manche Spalten sind in der Tat Settings. Die werden aber benötigt, z.B. sind manche Settings die Position (X, Y), der Online-Status oder aber auch nur, wie viele Lebenspunkte der Spieler hat und was seine Werte sind.
Mit ID, Name, Passwort, EMail, X, Y, Status, Angriff, Verteidigung, Lebenspunkte, Maxlebenspunkte sind wir schon mal bei 11. Das geht rasend schnell in die Höhe, es gehören dann noch Sachen wie Vergiftung (Time-Datensatz, bis wann) oder Profil und Stufe usw.
Ich denke, dass bei einem Browsergame schon erwartet werden kann, dass viele Spalten benötigt werden! Ob es nun 80 sein müssen - keine Ahnung.

Zitat von cortex

normaliserung war ja bereits ein hinweis; wenn du damit nicht vertraut bist, wird's höchste zeit .-

http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

In Ordnung...
EDIT: Ich wusste zwar nicht, was Normalisierung ist, aber ich glaube, das tue ich bereits...
Wenn ich eine Tabelle mit Items habe, weise ich dem Item eine UserID zu, die auf nen Benutzer verweist. Das ist denke ich sowas...

Zitat von feuervogel

und wieso nicht? wenn du dein wissen für dich behälst (warum auch immer), behalte ich mein wissen auch vorerst für mich.

Es tut mir Leid, ich kann es hier leider nicht öffentlich posten. Die Daten würden spielinterne (serverseitige) Vorgänge enthüllen und demnach evtl. nur neue Ideen für Hacker usw öffnen.
Außerdem: Wer gibt schon freiwillig seinen SourceCode her ^^
Wenn du möchstest, kann ich ihn dir auch gerne schicken. Aber das ganze hier zu "verewgigen" und für alle Suchmaschinen zugänglich zu machen - nein, danke ;)

[feuervogel]

Zitat von Phaltôn

Es tut mir Leid, ich kann es hier leider nicht öffentlich posten. Die Daten würden spielinterne (serverseitige) Vorgänge enthüllen und demnach evtl. nur neue Ideen für Hacker usw öffnen.

Aha. Sowas hab ich mir schon fast gedacht. Wenn sich ein Browserspiel "hacken" lässt, weil Du das Datenbankschema veröffentlichst, krankt es doch an ganz anderer stelle. Naja, für einen kleinen Lacker am morgen hats gereicht.

Außerdem: Wer gibt schon freiwillig seinen SourceCode her ^^

Öhm, *hust* ... open source ... *hust*.

Außerdem: Wenn ich will, dass mir "die Öffentlichkeit" bei meinen Programmierproblemen hilft, zeige ich der Öffentlichkeit meinen Quellcode. Zumal ich jetzt - und ich will dir nicht zu Nahe treten - nicht irgendwelchen gottgesandten Code erwarte, dessen Geheimhaltung der wichtigste Schritt auf dem Weg zur Weltherrschafft ist.

Wenn du möchstest, kann ich ihn dir auch gerne schicken. Aber das ganze hier zu "verewgigen" und für alle Suchmaschinen zugänglich zu machen - nein, danke ;)

Ich verzichte.

Zitat von feuervogel

Aha. Sowas hab ich mir schon fast gedacht. Wenn sich ein Browserspiel "hacken" lässt, weil Du das Datenbankschema veröffentlichst, krankt es doch an ganz anderer stelle. Naja, für einen kleinen Lacker am morgen hats gereicht.

...wer ist schon perfekt? Ich jedenfalls nicht.
Und wenn ich verhindern will, dass in 10 Jahren noch Suchmaschinen meinen Quellcode in diesem Forum finden, lasse ich das lieber ;)

Zitat von feuervogel

Öhm, *hust* ... open source ... *hust*.

Ach ja... OpenSource is was tolles, wenn noch nicht mal das eigene Spiel fertig ist, ne. Schließlich sind ja auch alle Spiele im Internet OpenSource, dem sollte man natürlich folgen... Tue ich aber trotzdem nicht :P

Zitat von feuervogel

Außerdem: Wenn ich will, dass mir "die Öffentlichkeit" bei meinen Programmierproblemen hilft, zeige ich der Öffentlichkeit meinen Quellcode. Zumal ich jetzt - und ich will dir nicht zu Nahe treten - nicht irgendwelchen gottgesandten Code erwarte, dessen Geheimhaltung der wichtigste Schritt auf dem Weg zur Weltherrschafft ist.

Deswegen habe ich dir ja vorgeschlagen, ihn per PN zu schicken.
Hör mal, ich weiß, dass ich keine spezielle Hilfe erwarten kann. Trotzdem ist es ja meine Entscheidung. Wenn mir nicht geholfen wird, hattest du Recht und ich lag wohl falsch.

Zitat von feuervogel

Ich verzichte.

Wie du willst, mir ist es gleich.

Ich bitte dich jetzt darum, diesen Forenkrieg zu beenden. Ich will dir nix böses und werde dich auch nicht weiter stören.

[Crisps]

Um das ganze noch etwas komplizierter zu machen:
Maybe Normalizing Isn't Normal: http://www.codinghorror.com/blog/archives/001152.html
und http://de.wikipedia.org/wiki/Denormalisierung

So verwendet(e?) z.B. Flickr für seine tag-clouds ein denormalisiertes DB Design. Es hängt also ganz davon ab, wie man seine Applikation und die DB verwendet. Allerdings kann man durchaus sagen, dass ein denormalisiertes Design oft schneller ist als ein normalisiertes - dafür aber auch deutlich fehleranfälliger.

Trotzdem ist mir ganz deutlich aufgefallen: Jede neue Abfrage aus PHP braucht erst mal eine Grundzeit. Das heißt: Mit jeder neuen Abfrage steigt zwingend die Ladezeit - je größer die Tabelle bzw. je größer die Datenmengen, desto mehr Zeit wird gebraucht (ist so meine Erfahrung).

Das kann natürlich auch an PHP selbst liegen, oder besser gesagt der verwendete Code der die Abfrage verwertet. Vielleicht kannst du die verwendete Abfrage mal in phpMyAdmin eingeben - Wenn sie auch dort langsam ist, liegt es wahrscheinlich an der Query selbst und/oder an einem nicht adequaten Index in der Tabelle.