2009-07-29 10 views
3

Ich habe hier ein paar Fragen zum Speichern von Benutzereinstellungen gesehen, aber sie scheinen sich hauptsächlich auf eine minimale Anzahl von Einstellungen zu beziehen. Ich arbeite gerade an einer hochgradig anpassbaren Web-App, die eine große Anzahl von Einstellungen speichern muss, und ich habe Probleme damit, sie zu speichern.Speichern sehr feinkörniger Benutzereinstellungen

Die Art von Einstellungen, die ich speichern werde, umfassen boolesche Werte zum Anzeigen bestimmter Tooltips, Anordnung verschiedener Inhaltsfelder auf einer Seite, anzuzeigende Seite nach dem Anmelden, Standardwerte für bestimmte Formularfelder usw. Alles in allem Ich erwarte, dass es für jeden Benutzer 50+ Voreinstellungen dieses Typs gibt, wobei die Daten hauptsächlich Boolesche Werte und Ganzzahlen sind.

Ich bin kein großer Fan der Serialisierung, aber ich bin besorgt über die Skalierbarkeit der Speicherung jeder Präferenz als einzelne Zeile. Gedanken?

Antwort

4

Serialisierung eines Datenblobs ist der Weg, hier zu gehen, aber nicht aus Leistungsgründen - eher weil dies ein Aspekt des Systems ist, das wahrscheinlich eine große Anzahl von Änderungen sehen wird.Sie möchten Ihr DB-Schema nicht ändern müssen, nur weil Sie eine Einstellung zulassen müssen, um den erweiterten Modus auf einer Seite oder etwas zu aktivieren.

Das Entity-Attribut-Wert-Modell, das HLGEM erwähnt, passt aus einer "leicht zu entwickelnden" Perspektive, aber wie er sagt, würde es sehr schlechte Leistung haben.

Was Sie mit serialisierten Objekten aufgeben würden, wäre die Möglichkeit, die db für Benutzer abzufragen, die einem bestimmten Muster entsprechen (vielleicht finden Sie einen Fehler, der nur mit einer Kombination von Einstellungen auftreten würde und Sie sehen möchten) wenn Sie Benutzer haben, die diese Kombination haben).

+2

"Das Entity-Attribut-Wert-Modell, das HLGEM erwähnt, passt dazu aus einer" leicht zu entwickelnden "Perspektive, aber wie er sagt, würde es sehr schlechte Leistung haben." Eigentlich hat sie das gesagt. – HLGEM

2

was auch immer Sie tun, vermeiden Sie die Entity-Attrtivute-Wert-Struktur für diese (http://en.wikipedia.org/wiki/Entity-Attribute-Value_model), es sei denn, Sie wollen ein sehr schlecht durchführendes System. Ein Aufruf an eine Tabelle mit 50 Spalten ist wesentlich schneller als ein Aufruf an eine Tabelle, der Sie 50 Mal beitreten müssen, um alle benötigten Informationen zu erhalten.

Ich würde eine verwandte Tabelle für jede allgemeine Gruppe von Voreinstellungen erstellen (Anmeldeeinstellungen, allgemeine Voreinstellungen für Webseiten, bestimmte Seiten oder Funktionen) basierend darauf, wie Sie nach Voreinstellungen abfragen möchten (wenn Sie alle wieder einschalten möchten) login vice zieht diejenigen, die für die gesamte Site beim Login benötigt werden, und diejenigen, die nur für spezielle Bereiche benötigt werden, wenn der Benutzer diese trifft, also einige Kombinationen davon, und haben die booleschen Spalten für den Typ von Präferenzen, die darin eingestellt sind. Auf diese Weise werden alle Präferenzen, die Sie für jeden Bereich der Site benötigen, in derselben Tabelle oder in höchstens zwei oder drei Tabellen gespeichert, was es relativ einfach macht, die Informationen zurück zu bekommen. Dies ist ein Ort, an dem Design für die Performance entscheidend ist (Sie werden ständig nach Präferenzen suchen, also sogar Millisekunden zählen), so dass Sie die Leistung zuerst in Ihrem Design berücksichtigen sollten. Es ist hier weitaus wichtiger als der Wunsch, dies objektorientiert erscheinen zu lassen oder dem Entwickler beim Aufbau weniger Arbeit zu verschaffen.

0

Ich weiß nicht, ob ich sogar Informationen wie Benutzereinstellungen in einer Datenbank speichern würde. Es scheint, dass Sie sich viele (wenn nicht alle) Benutzereinstellungen ansehen möchten, sobald sich der Benutzer anmeldet. Wenn Sie mehrere db-Abfragen ausführen, wird Ihr System ziemlich langsam. Stattdessen würde ich empfehlen, ALLE Einstellungen des Benutzers in einer einzigen Datei (oder einem einzelnen Datensatz) zu speichern, und es groß zu speichern und zwischenzuspeichern, sobald sich der Benutzer anmeldet.

0

Vorausgesetzt, die Benutzerdaten sind bereits gespeichert In einer Datenbank sehe ich dann kein echtes Problem, wenn ich alles in einer Zeile abspeichere, vor allem, wenn Sie Abfragen basierend auf den Daten durchführen müssen. Wählen Sie alle Benutzer mit Präferenz A ODER B etc.

Ich würde es jedoch in eine Klasse laden und diese Klasse über eine Art Caching-Mechanismus beibehalten.

0

Wenn Sie nicht nach den Voreinstellungen suchen müssen, können Sie die Voreinstellungen immer als XML speichern und in einer Spalte "Preference" speichern. Sollte das Hinzufügen neuer Präferenzen in Zukunft ein bisschen einfacher machen;)

0

Eine andere Option, die Sie tun könnten (wenn Sie Ihre Artikel nicht in einer DB gespeichert haben, zum Beispiel um Statistiken nach Material zu sehen (wer macht was usw.)), könnten Sie einfach alle ihre Einstellungen in einen Cookie setzen und auf ihrem Rechner speichern.

natürlich, mit Cookies kommt alle Vorbehalte der Verwendung von Cookies. aber nur eine andere Idee ...

0

Es gibt bestimmte Präferenzen, die der Benutzer bevorzugt (alle Tiere sind gleich, aber einige sind gleicher als andere). Diese sollten speziell für den Abruf und die Anwendung auf der Oberfläche beim Login optimiert werden. Wenn die Tiefe der Präferenz abnimmt, können sie unter Verwendung beliebiger Kriterien aggregiert und als separate Spalten gespeichert werden, möglicherweise als Arrays (z. B. Schriftartvorzugsspalte umfasst Schriftart, Größe und Farbe und bezieht sich auf eine Schriftartentabelle). Indizieren Sie auch die stark genutzten Spalten mithilfe von db tooling und Redesign, um aggregierte Spalten aufzuteilen, sodass Sie erkennen können, welches Element in der Aggregation stark beansprucht wird.

Alles in allem neigen die Benutzereinstellungen dazu, sehr statisch zu sein (d. H. Wie eine Gewohnheit), verwechseln Sie nicht die Benutzerdaten, die mit den Präferenzen stärker veränderbar sind.

Verwandte Themen