Ein besseres Datenbankdesign?

Question

Ich entwerfe eine Datenbank und bin in einen Haken geraten. Ok, nicht so ein Problem, als nur etwas, das ich nicht mag. Ich werde bis zu 1000 verschiedene Szenarien haben, und in jedem Szenario muss ich den Zustand von jedem von 64 verschiedenen Toggles speichern. Ich habe dies um gearbeitet, so gut ich kann, und habe mit dem folgenden kommen:

Table Scenario 

Scenario_ID 
Scenario_Name 


Table Toggles 

Scenario_ID 
Toggle_1 
Toggle_2 
... 
... 
Toggle_64 

Dies läßt mich, dass mit einer 65 Reihe Blendet Tabelle. Ich denke immer, dass es einen besseren Weg geben muss, als 64 Spalten "an" oder "aus" zu haben, aber ich weiß nicht, was es sein könnte. Ich möchte den Umschaltstatus in einer CSV-Datei nicht in einer Spalte speichern, da er sich ständig ändert und häufig analysiert werden muss. Es wäre viel einfacher für mich, die Tabelle zu aktualisieren, indem ich einfach Toggle_14 auf "aus" aktualisiere, anstatt eine CSV zu analysieren, sie zu ändern und neu zu laden. Irgendwelche Gedanken?

Answer 1

Verwenden Sie eine Many-to-Many Beziehung:

Table Scenario (Id, Name) 


Table ScenarioToggles (ScenarioId, TogglesId, ToggleState) 


Table Toggles (Id, ToggleName) 

Das Feld, ToggleState in der ScenarioToggles Tabelle wird die Ein/Aus-Wert halten.

Es ergibt auch etwas Flexibilität, wenn Sie mehr als 64 Wechsel benötigen.

Answer 2

können Sie entwerfen Toogles Tabelle es wie folgt aus:

Scenario_ID 
Toogle_nr 
Toogle_state 

und 64 Einträge für jedes Szenario erhalten.

Allerdings, wenn Toogles zählen wird nicht oft ändern und in jedem Szenario benötigen Sie alle Toogles, Ihre Lösung scheint die beste und einfachste zu sein.

Answer 3

Es ist ein Hack (irgendwie, ish, irgendwie), aber abhängig von Ihren Lookup-Anforderungen könnten Sie nur eine einzelne 64-Zeichen-Zeichenfolge speichern, auf die Sie in Ihrer Programmiersprache als Array zugreifen könnten.

Allerdings überwiegen die vielen, vielen, Nachteile dieses Tun mehr als wahrscheinlich die Vorteile. (Andererseits ist das Speichern von 64 Bits einer umkehrbaren Zustandsinformation in einer Datenbank eine ziemlich merkwürdige Anforderung an erster Stelle.)

Answer 4

MySQL's BIGINT Typ ist zufällig 64 Bits, so dass Sie es für die Speicherung von bis zu 64 Flags verwenden können a bit field. Technisch bricht dies die erste normale Form (nur ein Wert pro Spalte), aber das ist in Ordnung, wenn 1) Sie nie mehr als 64 Flags haben und 2) Sie die Flags immer als Gruppe abrufen.

Alternativ können Sie jedes Flag in einer separaten Zeile speichern, wie zum Beispiel:

 
     composite key 
    ===================== 
    Scenario_ID Toggle_ID Value 
     1   0  0 
     1   1  1 
     1   2  1 
     (...) 
     1   63  0 
     2   0  1 
     (...) 

Auf diese Weise mehr erweiterbar ist und macht es einfacher, mit einzelnen Flags in Abfragen zu behandeln, aber Sie werden 64 werden Abrufen Zeilen zu einer Zeit, wenn sie alle als eine Gruppe in der Anwendung behandeln.

Answer 5

Da Ihre Frage mit "mysql" getaggt ist, würde ich die Verwendung von the SET type empfehlen. Das Aktualisieren von Datensätzen zum Umschalten von Werten kann jedoch etwas schwierig sein, da MySQL zu diesem Zweck keine Funktionen anbietet (Suche nach REMOVE_FROM_SET im Bug-Tracker von MySQL als Workaround). Auf der anderen Seite ist es sehr kompakt und benötigt es nicht Sie können 64 Tabellen hinzufügen oder Aggregatfunktionen für jede SELECT-Abfrage verwenden.

Answer 6

Manche Leute versuchen nur, viel zu schlau zu sein. Verwenden Sie eine Tabelle mit Szenario-ID, Name und 64 Toggle-Spalten. Dies ist gut normalisiert, schnell, platzsparend und erweiterbar.