2010-12-27 9 views
7

Ich habe Einstellungen für den Benutzer über 200 Einstellungen, diese enthalten Benachrichtigungseinstellungen und Tracking-Einstellungen von Benutzeraktivitäten für Objekte. Das Problem ist, wie man es in der DB speichert? Sollte jede Einstellung eine Zeile oder eine Spalte sein? Wenn colunm dann wird Tabelle 200 Colunms haben. Wenn Zeile dann etwa 3 Spalten aber 200 Zeilen pro Benutzer x sogar 10 Millionen Benutzer = nicht gut.Benutzereinstellungen in Tabelle speichern - wie?

Also, wie sonst kann ich alle diese Einstellungen speichern? HINWEIS: Diese Einstellungen sind eine Mischung aus Texteingabe und FK-Lookups zu anderen Tabellen.

Danke.

+0

Wenn Sie nicht in einem Feld suchen müssen, können Sie sie alle in einem Textfeld serialisieren und speichern. Für mich ist das Erstellen einer Spalte pro Feld in Ordnung. Um die Suche/Auswahl zu verbessern, könnten Sie sie in mehrere Tabellen aufteilen wie user_profile, user_inteface_settings, user _... (Tabellen, die unabhängig verwendet werden können). - Erstellen einer generischen Tabelle, die Einstellungen enthält: Eine pro Zeile wie (uid, field, value) ist nützlich, wenn Sie viele optionale Felder haben und zu einer Tabelle mit 200 * 10 000 000 = 2 000 000 000 Zeilen führen können. –

+1

Mdillion - nur um Sie zu erinnern, sollten Sie die Antwort "akzeptieren", die Ihnen am meisten geholfen hat. –

+0

Mein Problem ist immer noch nicht gelöst. Es gibt so viele Einstellungen und beide hier genannten Wege funktionieren nicht richtig. Also erkunde ich einige andere Optionen und sobald ich etwas finde, werde ich die nächste Antwort akzeptieren. – Mdillion

Antwort

3

Die 200 zu überwachenden Einstellungen weisen auf ein flexibles Datenbankschema hin. Als solche würde ich einen hybriden Ansatz vorschlagen:

  1. Benutzer: Tabelle mit der Zeile pro Benutzer für Eigenschaften, die ein Benutzer wird wahrscheinlich immer, wie Benutzernamen und ein Passwort. Diese Tabelle kann auch Fremdschlüssel enthalten, dies ist jedoch eine Heuristik und hängt auch davon ab, ob die Beziehung 0: 1 oder 0: 0 ist. Wo letzteres eine separate Tabelle erfordert.
  2. Eigenschaften: zwei Optionen
    1. Tabelle mit Zeilen pro Funktion, effektiv eine Hash-Tabelle, mit userId, Namen und Wert Spalten. Dies könnte auch ein Ort für fremde Beziehungen sein, aber Sie wären nicht in der Lage, Datenintegrität in diesem Setup zu erzwingen.
    2. XML, aber nur mit einer Datenbank, die über Funktionen verfügt, mit denen Sie die Daten abfragen können oder nur für Daten, die Sie nicht abfragen müssen, sondern nur mit Ihrem Anwendungsserver arbeiten.

Ich denke, die größer Antwort ist, dass Sie werden nicht an einer Lösung von Ihrer ursprünglichen Frage kommen, sondern beide verwenden müssen, um die Daten zu entsprechen.

+0

Was ist das? Lesezeit, wenn die Tabelle 10 Millionen Zeilen hat und 200 Einstellungen für einen Benutzer benötigt, um die Einstellungsseite zu laden? Wird der Benutzer die Seite sofort sehen oder dauert es eine Minute, bis er die Benutzerseite sucht und lädt? – Mdillion

+0

Mit den richtigen Indizes sollte Lesezeit gut sein. Das heißt, ich würde vorschlagen, Informationen einmal bei der Anmeldung als Teil der Benutzersitzung zu laden, anstatt Datenbank-Trips jedes Mal zu wiederholen, wenn eine Berechtigung überprüft werden muss. – orangepips

2

Ich denke, 200 Spalten ist definitiv keine gute Idee, wegen der Schwierigkeit beim Schreiben gespeicherter Procs, manuelle Anzeige von Daten oder Erweiterung auf weitere Einstellungen später.

Können Sie XML für alle diese 200 Einstellungen ausprobieren und dann haben Sie nur 1 Zeile pro Benutzer. Benutzername und entsprechende Einstellungen xml. Aber auch hier werden Ihre Abfragefunktionen eingeschränkt, aber DBs unterstützen jetzt XML. Sie können XML-DBs gezielt auschecken.

+0

Können Sie FKs in XML setzen? – Mdillion

+0

Ich bin mir nicht sicher über ganze Details, aber es kann getan werden. Lesen Sie hierzu: http://www.stylusstudio.com/xsllist/200205/post70200.html http://msdn.microsoft.com/en-us/library/ms345117(v=sql.90).aspx –

4

Das Serialisieren der Daten stellt sich fast immer als schlechte Idee heraus, weil Sie dadurch die dbms lahm legen. Alle Mannjahre, die in die Produktion eines effizienten dbms mündeten, werden für einen serialisierten Eimer von Bits verschwendet.

Wenn Sie Anwendungslogik gegen jede Einstellung angeschlossen haben, ich glaube, Sie es als entweder implementieren sollten:

1 Spalte pro in den Einstellungen Tabelleneinstellung. Dies macht es einfacher, die Leistung Ihres dbms zu nutzen, mit Constraint-Prüfung, referenzieller Integrität, korrekter Datentyp für Ihre Werte, viel Information für den Optimierer. Der Nachteil ist, dass die Zeilengröße wächst.

oder

1 Tabelle pro Einstellung (oder eine Gruppe von verwandten Einstellungen). Dies hat alle Vorteile der oben genannten, aber handelt Zeilengröße für eine Leistungseinbuße, wenn Sie die meisten oder alle Einstellungen auf einmal abrufen müssen.Wenn die Einstellungen optional sind, ist diese Alternative wesentlich kleiner, wenn die tatsächlichen Daten spärlich sind.

Auch viele Spalten sind oft ein "Geruch", was darauf hindeutet, dass Sie Ihre Daten nicht korrekt normalisiert haben, aber das muss nicht so sein. Nur Sie kennen Ihre Daten.

+0

Viele Spalten sind wegen "Datenschutzstufen pro Benutzeraktivität". Jede Benutzeraktivität hat eine vom Benutzer definierte Datenschutzstufe und eine vom Standardsystem definierte Datenschutzstufe. Für die Systemeinstellung ist es in Ordnung, aber Benutzereinstellungen geraten außer Kontrolle, wenn wir 200 Aktivitäten mit jeweils eigenen Einstellungen haben. – Mdillion

Verwandte Themen