Memorizzazione di selezione multipla e selezione singola insieme

0

Ho un database con alcuni campi a selezione multipla. Per semplificare, diciamo che quei campi sono MatchGender e Interessi. Voglio che gli utenti siano in grado di trovare persone che corrispondono (quindi Gender è una selezione multipla, possono scegliere di confrontarsi con uno o entrambi i sessi) e interessi / hobby. Insieme a questi campi, ci sono diversi campi "selezione singola" come la città dell'utente, lo stato, il loro genere, ecc ...

Sto cercando di capire il modo migliore per archiviare questi dati in modo che sia facilmente ricercabile. Memorizzo i dati a selezione multipla in un singolo campo che è delimitato da virgole? Lo metto in una tabella separata con un ID utente? Pro / Contro di ciascuno?

A proposito, questo è un database back-end di SQL Server a cui si accede tramite un'interfaccia web ASP.

    
posta Johnny Bones 12.06.2015 - 17:22
fonte

1 risposta

5

Crea una tabella di interessi, quindi un'altra tabella (UserInterest) contenente le chiavi esterne di Utente e Interesse

Quello che stai descrivendo è una relazione molti-a-molti tra Utente e Interesse. Se segui il processo di normalizzazione del database per il tuo modello di dati, vedrai che il possesso di un elenco di valori separati da virgola non riesce su due punti:

  1. Ogni colonna deve contenere solo un elemento di dati, ma un elenco separato da virgola è composto da più elementi.
  2. Ogni interesse è un elemento di dati ripetuto nell'utente. Se avevi bisogno di cambiare qualcosa (magari correggendo un errore di ortografia, o cambiando il nome in qualcosa di più descrittivo), allora se si detengono gli Interessi come stringhe nella tabella Utente, è necessario eseguire una massiccia istruzione di aggiornamento sull'utente .

La combinazione di tenere tutto in User e contenere liste separate da virgole fa il secondo problema; se avessi bisogno di cambiare il nome di un interesse, non saresti in grado di eseguire un aggiornamento molto semplice - dovresti fare una sorta di manipolazione delle stringhe per trovare ogni istanza di un interesse e modificarlo.

Con la struttura che ho suggerito, se dovessi cambiare il nome di un interesse, aggiornerai una riga nella tabella degli interessi.

Inoltre, in questo modo significa che non avrai mai bisogno di manipolare le stringhe per far combaciare gli interessi tra due persone. Se tu avessi gli interessi della Persona A come "pesca, cottura, artigianato di carta" e Persona B come "slittino, mestiere di carta, pesca" dovresti fare qualche spiacevole scambio di dati per capire che condividevano i due terzi dei loro interessi . Invece, puoi semplicemente fare una serie di join - e con le funzioni di aggregazione in SQL potresti anche fare cose come capire il numero di interessi corrispondenti, la percentuale di interessi abbinati, ecc.

Infine, ti ringrazierai più tardi se hai bisogno di creare report, business intelligence o altri sistemi a valle su questi dati. O rimarrai nei buoni libri di chi è chi ha bisogno di costruire quelle cose.

    
risposta data 12.06.2015 - 18:09
fonte

Leggi altre domande sui tag