Progettazione del DB:tabella dei membri separata o tutta in una tabella?

Question

Voglio creare una tabella di amici con informazioni personali e dettagli di accesso.

Cosa meglio separare la tabella dei membri in 2 tabelle, una contiene dettagli minimi, secondo con altri dettagli.

o rimanere in un tavolo?

ho molte tabelle che contengono la chiave esterna del membro.

Answer 1

Dipende molto da quali sono quegli "altri" dettagli.Questa è una domanda comune e interessante e a prima vista non esiste una risposta "dura e veloce".Ma se pensiamo alla questione in modo più astratto, alla relazione effettiva tra gli attributi ("dettagli") di ogni cosa particolare che vogliamo rappresentare, potremmo trovare una certa chiarezza.

Nella tua domanda affermi che gli amici hanno dettagli "minimi" e "altri".Invece di classificare questi dettagli come "minimi" o "altri", classifichiamoli in base al fatto che qualsiasi dettaglio individuale ("atomico") possa essere pienamente determinato o meno da ciò che rende unico un amico.

Presumo che ci sia una chiave primaria (PK), come FriendID o indirizzo e-mail o qualcosa del genere.Considerando questo identificatore univoco, chiediti:"Se mi viene fornito esattamente un FriendID (o un'e-mail o qualunque cosa tu stia utilizzando come PK) di quali dettagli di quell'amico sono assolutamente sicuro?Ad esempio, dato FriendID=2112, conosco assolutamente il nome, il cognome e la data di nascita dell'amico, ma non conoscere assolutamente il numero di telefono di quell'amico perché ce n'è più di uno.

Raggruppa in un'unica tabella tutti i dettagli che conosci inequivocabilmente dato il PK.Inserisci i dettagli per i quali hai bisogno di più dati (come "casa" o "lavoro" nel caso dei numeri di telefono) nelle tabelle "figlie", con chiave esterna nella tabella "genitore" sul PK.(Nota:È estremamente probabile che il PK della tabella figlio sia composito;ovvero, composto dal PK della tabella padre e dal fattore di differenziazione (come "casa" o "lavoro" in questo esempio).Le chiavi composite per i molti lati delle relazioni 1-M sono molto buone.)

I fanatici dei database chiamano questa scomposizione basata su dipendenze funzionali.

Answer 2

Una tabella, a meno che potenzialmente necessario associare un membro di più set di dati (vale a dire più indirizzi e-mail, gruppi di utenti, giorno-phone, night-phone, telefono cellulare, ecc) .

Answer 3

Non ci sono dubbi:. Sempre contempla tavoli quando ha senso logico

Ad esempio:   Amico 1: Tom Jones vive a The Valley   Amico 2: Erin Jones vive la loro troppo dal momento che è il fratello

tabelle:

Friends
Id  Name          Address
1   Tom Jones     1
2   Erin Jones    1

Adresses 
Id Address
1  The valley

In caso contrario, le cose sempre si presenti come:

Friends
Id  Name          Address
1   Tom Jones     The Valey
2   Erin Jones    The Valley

che porterà alle richieste errate.

Questa è solo una questione, ci sono numerosi. Come quello che in tal caso ha 2 indirizzi di posta elettronica e 3 numeri di cellulare? Cosa succede se un nome della via cambia e 5 amici vivono in esso?

Se sono molto sicuro la vostra tavola sarà piccolo, e non si deve interrogare, di quanto si potrebbe utilizzare un solo tavolo. Ma quanto si può semplicemente utilizzare alcuni excell come sw anche, o un pezzo di carta per questo: -)

Ma se si vuole avere una base di dati, trattarlo come uno.

normalizzazione per l'intera questione.