Database: Ha senso scegliere il codice postale come chiave primaria per un indirizzo?

Question

Database: Ha senso scegliere il codice postale come chiave primaria per un indirizzo?

#1 da (13 voti)
#2 da (4 voti)
#3 da (3 voti)

2

Stavo seguendo un tutorial sulle normali forme di database SQL, e mi sono confuso approdando su questo esempio: link .

Da

CREATE TABLE CUSTOMERS(
   CUST_ID       INT              NOT NULL,
   CUST_NAME     VARCHAR (20)      NOT NULL,
   DOB           DATE,
   STREET        VARCHAR(200),
   CITY          VARCHAR(100),
   STATE         VARCHAR(100),
   ZIP           VARCHAR(12),
   EMAIL_ID      VARCHAR(256),
   PRIMARY KEY (CUST_ID)
);

Crea una nuova tabella ADDRESS in questo modo perché esiste una "dipendenza transitiva tra zipcode e indirizzo".

CREATE TABLE ADDRESS(
   ZIP           VARCHAR(12),
   STREET        VARCHAR(200),
   CITY          VARCHAR(100),
   STATE         VARCHAR(100),
   PRIMARY KEY (ZIP)
);

Questo è il posto in cui sono davvero confuso. Perché utilizzare il codice postale come chiave primaria? Le chiavi primarie devono essere uniche, non puoi avere due indirizzi con lo stesso codice postale?

In entrambi i

Non capisco come funziona un codice postale
Non capisco come funzioni una chiave primaria
Questo esempio è chiaramente sbagliato
Non capisco qualcos'altro.

sql database-design relational-database normalization

posta Ricola 28.11.2018 - 17:14

fonte

3 risposte

4

L'utilizzo di un codice postale come chiave primaria sarebbe errato. L'autore del tutorial è corretto in quanto le tabelle dovrebbero essere attentamente esaminate per determinare cosa può essere suddiviso per ridurre grandi quantità di dati duplicati nel grande schema delle cose. Tuttavia, un codice postale non è univoco in quanto più di un cliente potrebbe (e molto probabilmente lo sarebbe) vivere nello stesso codice postale. Anche se vengono aggiunte le 4 cifre extra utilizzate dall'ufficio postale, non è sempre sempre univoco. Anche l'indirizzo stesso non sarebbe unico, poiché più di un residente in una famiglia potrebbe essere un cliente. In effetti, la migliore linea di azione sarebbe quella di creare un ID univoco per la tabella, se l'indirizzo verrà suddiviso in questo modo, poiché qualsiasi combinazione per una chiave composita non rimuoverà la possibilità di duplicare le chiavi. L'esempio di tutorialspoint non è un buon esempio o un esempio corretto di 3nF.

Le basi da cercare in ogni modulo di normalizzazione sono le seguenti:

1nF: assicurati che non ci siano colonne duplicate (orizzontali).
2nF: rompi le tabelle fino a quando non c'è un solo scopo. Come rompere una tabella cliente che include gli ordini in modo che i clienti e gli ordini siano separati.
3nF: "Transitivo" significa semplicemente che una colonna può essere determinata da un'altra senza guardare la chiave primaria. Come una tabella ordini del cliente, potrebbero avere come ID dell'ordine, cliente, produttore e prodotto come colonne. Il prodotto può essere determinato dal produttore, quindi la colonna del prodotto o viceversa non deve in realtà fare affidamento sul numero dell'ordine. Questa sarebbe una tabella in cui potrebbe essere suddivisa in due tabelle in cui ID prodotto o produttore possono essere la chiave primaria. La nuova chiave primaria delle tabelle verrà quindi utilizzata come chiave esterna nella tabella degli ordini.
4nF: assicurati che ci sia solo una parte di dati in ogni colonna. Usiamo la tabella del produttore. Se la colonna del produttore è la chiave primaria, potrebbero esserci più di un prodotto nella stessa riga / colonna. Immagino che questo non sia il miglior esempio, ma spero che tu abbia l'idea. Quindi per 4nF ci si assicura che avere più di un pezzo di dati, come più prodotti, nello stesso posto non avvenga.

3nF e 4nF non sono sempre utilizzati dalle aziende come standard rigorosi, ma sono buoni da sapere e da usare quando possibile. Inoltre, come altri hanno menzionato l'utilizzo di un ID come chiave primaria invece di una delle colonne può essere molto utile. Ad esempio, invece di creare una chiave composita con nome, cognome e nome utente o memorizzare informazioni sensibili come il loro SSN, è possibile utilizzare un ID generato automaticamente come chiave primaria.

risposta data 29.11.2018 - 05:08

fonte

3

L'esempio è chiaramente sbagliato.

È un buon esempio di sovra-normalizzazione. Nel punto in cui normalizzi tutto ciò che è teoricamente possibile, crea una soluzione che non regge in futuro.

Codici postali anche quelli negli Stati Uniti che potrebbero sembrare piuttosto permanenti (non sono un esperto di codici postali statunitensi ma conferisco all'autore del tutorial il beneficio del dubbio) e possono definire che la strada non sia una buona chiave per indirizzi in generale.

In alcuni paesi ha senso avere una tabella di codici di avviamento postale per aiutare l'utente a inserire un indirizzo, ma l'indirizzo deve essere salvato per ogni record, non deve essere referenziato tramite una chiave.

Ma le strade cambiano i nomi, sono ricostruiti, divisi in due codici postali quando vengono costruiti nuovi alloggiamenti lungo di essi ecc.

In breve tempo uno degli indirizzi nel tuo database cambierà, forse il nome della via è cambiato. Ora modifichi la voce per il codice di avviamento postale e tutti gli altri indirizzi che utilizzano quel codice di avviamento postale ora sono sbagliati e in seguito non avrai idea del perché e non hai più la minima idea di quale fosse l'indirizzo prima della modifica.

Dove sono cresciuto potresti ricavare il codice postale dalle prime 4 cifre del numero di telefono. Se segui la logica dell'autore del tutorial, entrambi non potrebbero essere nella tabella dei clienti.

risposta data 28.11.2018 - 17:39

fonte

Leggi altre domande sui tag sql database-design relational-database normalization

Perché un database è rappresentato come un cilindro nei disegni di architettura? [chiuso] Svantaggi nell'uso di "array associativi" in JavaScript

score 13 · Accepted Answer

L'esempio sta commettendo un errore fondamentale: sta usando i dati come chiave primaria. Dovrebbe creare e utilizzare ID univoci.

I commenti discutono su quanto sia corretto presumere che un codice postale sia associato a una determinata strada. Che sia corretto o meno, il semplice fatto è che per farlo funzionare senza un ID univoco deve essere corretto, non solo ora ma per sempre di più. Questo è esattamente il motivo per cui è sbagliato farlo. Non puoi conoscere il futuro. Utilizza un ID univoco.

Se zipcode identifica in modo univoco i dati che stai normalizzando ora hai una chiave naturale. Ma aggiungere solo un altro record può distruggerlo. Le chiavi naturali possono essere utilizzate quando si importano dati per aiutare a creare relazioni ID univoche. Non dovrebbero essere utilizzati quando un'applicazione raccoglie dati da un utente che può garantire che la relazione sia reale.

Le persone ottengono questi due casi d'uso di dati strutturati confusi tutto il tempo. Gli ID univoci dovrebbero sempre essere preferiti nei sistemi operativi. Il problema è che non sempre esistono. Quando non lo fanno, possiamo costruire l'unicità selezionando i campi dati come chiavi naturali mentre normalizziamo. Ma quell'unicità costruita è SEMPRE fragile. Potrebbe essere vero solo ora. Va bene usare il fatto che ora è vero generare ID univoci. Ma dopo che i nuovi dati dovrebbero essere assegnati correttamente ID univoci.

Gli ID univoci non si corrodono via via che vengono aggiunti più dati. Le chiavi naturali spesso lo fanno. Gli sviluppatori che mettono in campo sistemi che insistono sul fatto che le loro assunzioni chiave naturali valgano a prescindere dalla realtà spesso causano problemi che gli operatori si trovano a dover risolvere. Per favore, non farlo.