SQL wissen, wann Tabellen zu teilen

Ich erstelle eine Datenbank, die Replays für ein Spiel verfolgt. Jede Wiederholung hat einen anderen Spielmodus, der entweder teambasiertes Gameplay oder individuelles Gameplay ist. Abhängig vom Spielmodus möchte ich das gewinnende Team oder die gewinnende Person aufnehmen.SQL wissen, wann Tabellen zu teilen

Ich habe folgende MySQL-Tabelle, die Runden in der Wiedergabe und der damit verbundenen Sieger verfolgt:

CREATE TABLE replay_rounds (
    replay_id INT UNSIGNED NOT NULL, 
    round SMALLINT UNSIGNED NOT NULL, 
    winning_player_id INT UNSIGNED, 
    winning_team_id TINYINT UNSIGNED, 
    FOREIGN KEY (replay_id) REFERENCES replays(id), 
    FOREIGN KEY (replay_id, winning_player_id) REFERENCES replay_players(replay_id, player_id), 
    FOREIGN KEY (winning_team_id) REFERENCES teams(id), 
    PRIMARY KEY (replay_id, round)) 
CHARACTER SET=utf8 
COLLATE=utf8_general_ci 
ENGINE=InnoDB;

Mit was ich jetzt habe, wenn das Spiel-Modus ist Team-basierte dann werde ich die winning_team_id für jeden Satz runde und setze die winning_player_id auf null. Ebenso, wenn der Spielmodus individuell ist, setze ich die winning_team_id auf null.

Leistungsmäßig und in Bezug auf Best Practice, ist es in Ordnung, es so zu verlassen? Gibt es einen zwingenden Grund, diese für jeden Spielmodus in eine separate Tabelle aufzuteilen (auch wenn es nur zwei Modi gibt)? Wie wäre es mit einer hypothetischen Situation, in der Spielmodi ständig hinzugefügt werden - würde dies am besten gelöst werden, indem für jeden neuen Spielmodus eine Tabelle erstellt wird?

Quelle

2009-07-23 Kai

Ich hätte nur eine winning_id (lösche die individuellen Gewinn-IDs für Team und Spieler) und ein zusätzliches Attribut für game_type_cd. Dies ist ein Suchattribut, das ein Fremdschlüssel für eine neue Tabelle namens GAME_TYPE_COES ist. Dann müssen Sie nur die gewinnende_id und den Spieltyp eingeben. Dies ermöglicht eine unendliche Anzahl von Spieltypen, bei denen nur Daten zur Tabelle GAME_TYPE_CODEs hinzugefügt werden müssen und die Datenstruktur nicht geändert werden muss.

Quelle

2009-07-23 16:42:53 northpole

Dies würde funktionieren, wenn die Winning_id für jeden Spielmodus den gleichen Typ hat. In meinem Beispiel ist winning_id ein TINYINT, wenn es ein Team ist, und winning_id ist ein INT, wenn es sich um ein Individuum handelt. Ich könnte einfach INT wählen, da es eine Obermenge von TINYINT ist, aber das scheint ein Zufall/Hack zu sein. – Kai

Ich denke, Ihr "Hack" wäre hier eine gute Wahl, um die Datenbank zu normalisieren. – northpole

Punkt gut gemacht :) Ich muss lernen, weniger Perfektionist zu sein und spezifische Lösungen für Probleme anzuwenden. – Kai

Ich denke, dass diese Datenbank sollte relational sein - Vielleicht 1 Tabelle für die (Person/Team-ID), dann eine andere, die Gameeid/(Team/Person-ID)/win bezeichnet, dann eine andere, die ID/Replayinfo/etcetc hat

So ..

TeamID | Name 
------------- 
    1 | Thunderbirds 
    2 | John Petravich 

GameID | TeamID | Win? 
----------------------- 
    1 | 1 | 1 
    2 | 2 | 0 

ReplayID | GameID | (Your table's other properties) 
---------------------------------- 
    1 | 1 | etc

Jetzt können Sie die Beziehung verwenden, um alle die verschiedenen Informationen zu einem bestimmten Team oder einzelne zu bestimmen. Wenn Sie Seiten basierend darauf anpassen müssen, was sie sind, fügen Sie der ersten Tabelle eine Typspalte hinzu und zeigen Sie Ihre Seiten basierend auf dieser Typ-ID an.

$ .02

Quelle

2009-07-23 16:48:27

Ich würde vorschlagen, WP: Database normalization zu lesen. Vor allem die sind wissenswert, wenn über das Teilen/Vereinheitlichen von Tabellen diskutiert wird ...

Quelle

2009-07-23 16:49:18

SQL wissen, wann Tabellen zu teilen

Antwort

Verwandte Themen