Memorizzazione delle impostazioni utente nella tabella: come?

Question

Sono disponibili per l'utente circa 200 impostazioni, tra cui le impostazioni di avviso e le impostazioni di tracciamento dalle attività dell'utente sugli oggetti. Il problema è come archiviarlo nel DB? Ogni impostazione dovrebbe essere una riga o una colonna? Se la tabella successiva avrà una tabella di 200 colonne. Se fila allora circa 3 colonne ma 200 righe per utente x anche 10 milioni di utenti = non va bene.

Quindi in che altro modo posso memorizzare tutte queste impostazioni? NOTA: queste impostazioni sono un mix di immissione di testo e ricerche FK su altre tabelle.

Grazie.

Answer 1

Le 200 impostazioni da tracciare suggeriscono uno schema di database flessibile. In quanto tale io suggerirei un approccio ibrido:

1. Utenti: tavolo con la fila per utente per le proprietà che un utente sarà probabilmente sempre avere, come ad esempio il nome utente e la password. Questa tabella può anche tenere le chiavi esterne, ma questa è un'euristica e dipende anche se la relazione è da zero a zero o da zero a molti. Dove quest'ultimo richiede una tabella separata.
2. Caratteristiche: due opzioni
   1. tavolo con riga per ogni funzione, in modo efficace una tabella hash, con UserID, nome e valore colonne. Questo potrebbe anche essere un punto per le relazioni estere, ma non sarebbe in grado di rafforzare l'integrità dei dati in questa configurazione.
   2. XML, ma solo con un database dotato di funzionalità che consentono di eseguire query sui dati o solo per dati che non è necessario eseguire una query, ma funzionano solo con il proprio server applicazioni.

Penso che la risposta più grande è che non si ha intenzione di arrivare ad una soluzione dalla tua domanda iniziale, ma invece necessario utilizzare sia per soddisfare i dati.

Answer 2

Penso che 200 colonne non sia sicuramente una buona idea, a causa della difficoltà nella scrittura di stored proc, visualizzazione manuale dei dati o estensione a più impostazioni in seguito.

Puoi provare XML per tutte queste 200 impostazioni e quindi avrai solo 1 riga per utente. nome utente e impostazioni corrispondenti xml. Ma di nuovo limiterà le tue capacità di interrogazione, ma i DB ora supportano XML. È possibile verificare in modo specifico i DB XML.

Answer 3

La serializzazione dei dati si rivela quasi sempre una cattiva idea, perché in tal modo si blocca i dbms. Tutti gli anni che sono andati a produrre un dbms efficiente verranno sprecati in un secchio di bit serializzato.

Se avete la logica dell'applicazione collegato contro ogni impostazione, penso che si dovrebbe applicare come sia:

1 colonna per l'impostazione della tabella impostazioni. Ciò semplifica l'utilizzo della potenza dei dbms, con controllo dei vincoli, integrità referenziale, tipo di dati corretti per i valori, molte informazioni sull'ottimizzatore. Lo svantaggio è che le dimensioni delle righe crescono.

o

1 tabella per ogni impostazione (o gruppo di impostazioni correlate). Questo ha tutti i vantaggi di cui sopra, ma consente di visualizzare le righe per una penalizzazione delle prestazioni quando è necessario recuperare la maggior parte o tutte le impostazioni contemporaneamente.Quando le impostazioni sono opzionali, questa alternativa sarà significativamente più piccola se i dati effettivi sono sparsi.

Inoltre, un sacco di colonne è spesso un "odore", che suggerisce che non hai normalizzato correttamente i dati, ma non deve essere in questo modo. Solo tu conosci i tuoi dati.