Memorizzazione di preferenze utente molto granulari

Question

Qui ho visto alcune domande sulla memorizzazione delle preferenze dell'utente, ma sembra che si riferiscano principalmente a un set di preferenze abbastanza minimale. Attualmente sto lavorando a un'app Web altamente personalizzabile, che dovrà archiviare un gran numero di preferenze e sto lottando su come memorizzarle.

Il tipo di preferenze che memorizzerò include i booleani per la visualizzazione di tooltip specifici, la disposizione di vari pannelli di contenuto in una pagina, la pagina da visualizzare dopo il login, i valori predefiniti per campi del modulo specifici, ecc. Mi aspetto che ci siano più di 50 preferenze di questo tipo per ogni utente, dato che i dati sono per lo più booleani e interi.

Non sono un grande fan della serializzazione, ma sono preoccupato per la scalabilità della memorizzazione di ogni preferenza come singola riga. Pensieri?

Answer 1

La serializzazione di un blocco di dati è la strada da percorrere qui, ma non per motivi di prestazioni, piuttosto perché questo è un aspetto del sistema che probabilmente vedrà un enorme numero di modifiche. Non è necessario modificare lo schema DB solo perché ora è necessario consentire a una preferenza di attivare la modalità avanzata su una pagina o qualcosa del genere.

Il modello entità-attributo-valore menzionato da HLGEM si adatta a questo da un "facile da evolvere" prospettiva, ma come dice avrebbe prestazioni molto scadenti.

Ciò che rinunciare agli oggetti serializzati sarebbe la possibilità di interrogare direttamente il db per gli utenti che corrispondono a un certo modello (forse stai rintracciando un bug che si verificherebbe solo con una combinazione di impostazioni e vuoi vedere se hai utenti che hanno quella combinazione).

Answer 2

qualunque cosa tu faccia, evita di utilizzare la struttura entità-valore-attrattivo per questo ( http: //it.wikipedia.org/wiki/Entity-Attribute-Value_model ) a meno che tu non voglia un sistema molto performante. Una chiamata a una tabella con 50 colonne sarà molto più veloce di una chiamata a una tabella a cui devi unirti 50 volte per ottenere tutte le informazioni di cui hai bisogno.

Realizzerei una tabella correlata per ciascun gruppo generale di preferenze (preferenze di accesso, preferenze generali del sito, preferenze di pagine o funzioni specifiche) basandomi su come intendi eseguire una query per le preferenze (se desideri ripristinare tutto all'accesso vice pull quelli necessari per l'intero sito al momento del login e quelli necessari solo per aree specializzate quando l'utente colpisce quelli, quindi una loro combinazione) e hanno le colonne booleane per il tipo di preferenze impostato in quello. In questo modo tutte le preferenze necessarie per ciascuna area del sito saranno nella stessa tabella o al massimo due o tre tabelle, rendendo relativamente semplice il recupero delle informazioni. Questo è un posto in cui il design è fondamentale per le prestazioni (cercherete continuamente le preferenze, quindi contano anche i millisecondi), quindi dovreste davvero considerare le prestazioni prima nel design. È molto più importante qui di qualsiasi desiderio di far sembrare che ciò sia orientato agli oggetti o di creare meno lavoro per lo sviluppatore nell'impostazione.

Answer 3

Non so se vorrei persino memorizzare informazioni come le preferenze dell'utente in un database. Sembra che vorrai esaminare molte (se non tutte) le preferenze dell'utente non appena l'utente accede; se finisci per fare un sacco di query db, il tuo sistema finirà piuttosto lentamente. Invece, raccomanderei di mantenere TUTTE le impostazioni dell'utente in un singolo file (o un singolo record da qualche parte) e di ingoiarlo all'ingrosso e memorizzarlo nella cache non appena l'utente accede.

Answer 4

Presumendo che i dati dell'utente siano già archiviati in un database, quindi non vedo alcun problema reale archiviarli tutti in una riga, soprattutto se potrebbe essere necessario eseguire query basate sui dati, ad es. seleziona tutti gli utenti con preferenza A OR B ecc.

Vorrei tuttavia caricarlo in una classe e persistere quella classe tramite una sorta di meccanismo di memorizzazione nella cache.

Answer 5

Se non è necessario cercare le preferenze, è sempre possibile memorizzarle come XML e salvarle in una " Preferenza " colonna. Dovrebbe rendere un po 'più semplice l'aggiunta di nuove preferenze in futuro;)

Answer 6

Un'altra opzione che potresti fare (se non hai bisogno che i tuoi articoli siano archiviati in un DB, ad esempio per controllare le statistiche per cose (chi fa cosa, ecc.)), puoi semplicemente mettere tutte le loro impostazioni in un cookie e archiviare sulla loro macchina.

ovviamente, con i cookie vengono fornite tutte le avvertenze sull'uso dei cookie. ma solo un'altra idea ...

Answer 7

Ci sono alcune preferenze che l'utente preferisce di più (tutti gli animali sono uguali ma alcuni sono più uguali di altri). Questi dovrebbero essere specificamente ottimizzati per il recupero e l'applicazione sull'interfaccia all'accesso. Man mano che la profondità della preferenza diminuisce, possono essere aggregati utilizzando qualsiasi criterio e salvati come colonne separate possibilmente come matrici (ad es. La colonna delle preferenze del carattere include il tipo, la dimensione e il colore del carattere e si riferisce a una tabella dei caratteri). Indicizza anche le colonne molto utilizzate utilizzando gli strumenti db e riprogetta per dividere le colonne aggregate in modo da poter identificare quale elemento nell'aggregazione è molto richiesto.

Nel complesso le preferenze dell'utente tendono ad essere molto statiche (cioè sono come un'abitudine), non confondere i dati dell'utente che sono più altamente mutabili con le preferenze.