Queste tabelle specifiche richiedono chiavi surrogate?
-
29-09-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
sfondo
Ho queste tabelle
+-------------------------+ +------------------------+
|Airport | |Country |
|-------------------------| |------------------------|
|airport_code string (PK) | |country_code string (PK)|
|address string | |name string |
|name string | +------------------------+
+-------------------------+
+-------------------------+
|Currency |
|-------------------------|
|currency_code string (PK)|
|name string |
+-------------------------+
Airport_code è il IATA (International Air Transport Association) Codice aeroporto , puoi vederli nei tuoi tag bagagli quando viaggi in aereo. 
Country_code è il ISO 3166-1 A3 Paese standard Codice , puoi vederli nelle Olimpiadi.
Valuta_code è il IS0 417 Codice valuta standard a 3 caratteri standard , puoi vederli nelle schede internazionali di cambio valuta.
Domande
sono questi PKS naturali abbastanza buoni?
utilizza gli standard rispettati del mondo, che sono accettati da intere industrie abbastanza buone per PKS?
Fai queste tabelle Hai bisogno di surrogati, non importa cosa?
Soluzione
No, non lo fanno.Queste chiavi sono sicuramente abbastanza buone!
Sono unici, non raramente andando a cambiare, e significativo , che è un passo avanti su una chiave surrogata.È praticamente la definizione di un buon PK.
Le restrizioni su PKS essere immutabili e numeriche-intero non fanno parte del modello relazionale (codd's) oQualsiasi standard SQL (ANSI o altro).
Altri suggerimenti
Penso che Hai bisogno è una parola molto forte, e in senso stretto, le tabelle probabilmente non bisogno chiavi surrogate . .
Tuttavia, se fosse il mio database, probabilmente aggiungerei chiavi surrogate comunque. Potrei non volere necessariamente che il mio design del database dipenda da un gruppo di terze parti (IATA, ISO), indipendentemente da quanto siano stabili i loro standard. Oppure, potrei non voler dipendere da uno standard particolare (ci sono altri standard di codice valutaria? Non lo so). Probabilmente modellino i miei tavoli con le chiavi surrogate come SO:
+-------------------------+ +------------------------+
|Airport | |Country |
|-------------------------| |------------------------|
|airport_id int (PK)| |country_id int (PK) |
|iata_airport_code string | |iso_country_code string |
|icao_airport_code string | +------------------------+
|faa_identifier string |
|address string |
|name string |
+-------------------------+
+-------------------------+
|Currency |
|-------------------------|
|currency_id int (PK) |
|iso_currency_code string |
|name string |
+-------------------------+
In altre parole, a meno che quei codici standard del settore non siano intrinsecamente importanti alla mia applicazione, non li userei come PK delle mie tabelle. Sono solo etichette. La maggior parte delle mie altre tabelle probabilmente avrà comunque chiavi surrogate e questa configurazione aggiungerebbe coerenza al mio modello di dati. Il costo di "aggiungere" le chiavi surrogate è minima.
Aggiornamento in base ad alcuni dei commenti:
Senza conoscere il contesto delle tabelle di esempio, è impossibile sapere quanto siano importanti cose come i codici Aeroporto IATA per l'applicazione utilizzando il database. Ovviamente, se i codici IATA sono centralmente importanti e utilizzati pervasamente durante tutta la domanda, potrebbe essere la decisione corretta, dopo una corretta analisi, utilizzare i codici come PK della tabella.
Tuttavia, se la tabella è solo una tabella di ricerca che viene utilizzata in alcuni angoli dell'app, l'importanza relativa dei codici IATA non può giustificare un punto di spicco simile nell'infrastruttura del database. Certo, potresti dover effettuare un ulteriore unire in poche domande qui e lì, ma questo sforzo potrebbe essere banale rispetto allo sforzo che ci vorrebbe per fare la ricerca per assicurarti di comprendere appieno le implicazioni di rendere i codici IATA Campo chiave primario. In alcuni casi, non solo non mi interessa, ma non voglio dover prendersi cura sui codici IATA. Il commento di @James Snell qui sotto è un perfetto esempio di qualcosa che potrei non voler preoccuparsi di influenzare il PK dei miei tavoli.
Inoltre, la coerenza nel design è importante. Se si dispone di un database con dozzine di tabelle che tutte hanno progettato costantemente chiavi surrogate, quindi alcune tabelle di ricerca che utilizzano codici di terze parti come PK, che introducono un'incoerenza. Non è del tutto male, ma richiede particolare attenzione nella documentazione e tale che potrebbe non essere giustificato. Sono tabelle di ricerca per il bene di bontà, solo usando una chiave surrogata per la coerenza è perfettamente soddisfacente.
Aggiornamento basato su ulteriori ricerche:
OK, la curiosità un bit me e ho deciso di fare qualche ricerca sui codici aeroportuali IATA per divertimento, a partire dai collegamenti forniti nella domanda.
AS Silent Out, i codici IATA non sono come universali e autorevoli come la domanda li rende. Secondo Questa pagina :
.La maggior parte dei paesi utilizza quattro caratteri codici ICAO , non i codici IATA, nel loro Pubblicazioni aeronautiche ufficiali.
Inoltre, i codici Itata e i codici ICAO sono distinti da Codici identificativi FAA , che sono ancora un altro modo per identificare gli aeroporti.
Il mio punto nel portare avanti questi non è quello di iniziare un dibattito su quali codici sono migliori o più universali o più autorevoli o più completi, ma per mostrare esattamente perché progettare la struttura del tuo database attorno a un identificatore arbitrario di 3a partito non è qualcosa che vorrei Scegli di fare, a meno che non ci fosse un motivo di business specifico per farlo .
In questo caso, sento il mio database sarebbe meglio strutturato, più stabile e più flessibile, perdendo i codici IATA (o qualsiasi 3a parte, codice potenzialmente mutevole) come candidato chiave primario e usa una chiave surrogata. In tal modo, posso rinunciare a qualsiasi potenziale insidenza che potrebbe ritagliare a causa della selezione della chiave primaria.
Mentre le chiavi surrogate sui campi vanno bene e non c'è niente di sbagliato in quel qualcosa da considerare potrebbe essere la dimensione della pagina dell'indice stesso.
Poiché questo è un database relazionale che farai molti unici e avete una chiave surrogata di un tipo numerico potrebbe rendere più facile nel gestire il database, cioè la dimensione della pagina dell'indice sarà più piccola e quindi più veloce per cercare il trogolo . Se questo è un piccolo progetto non importa e otterrai senza problemi comunque più grande che l'applicazione ottiene più che vorrai ridurre i colli di bottiglia.
Avere un bigint, int, small sting, tinyint o qualunque tipo di dati come intere-like-like potrebbe salvarti un po 'di problemi lungo la strada.
Solo i miei 2 centesimi
Aggiornamento:
Piccolo progetto - usato da pochi, forse anche alcune dozzine di persone. Piccola scala, progetto demo, progetto per uso personale, qualcosa da aggiungere a un portafoglio quando presenta le tue abilità senza esperienza, e simili.
Grande progetto - utilizzato da migliaia, decine di migliaia, milioni di utenti ogni giorno. Qualcosa che creeresti per una compagnia nazionale / internazionale con una grande base di utenti.
di solito ciò che accade è un selezionato alcuni dei record vengono selezionati spesso e il server memorizza i risultati per l'accesso rapido, ma di tanto in tanto è necessario accedere ad alcuni record meno utilizzato, a quel punto il server dovrebbe immergere nella pagina dell'indice. (Nell'esempio sopra con i nomi degli aeroporti, le persone spesso volano compagnie aeree nazionali, dicono Chricago -> Los Angeles, ma quanto spesso le persone volano da Boston -> Zimbabwe)
Se viene utilizzato Varchar che significa che la spaziatura non è uniforme, a meno che i dati non siano sempre la stessa lunghezza (a quale punto un valore di char è più efficace). Ciò rende la ricerca dell'indice più lento, e con il server già occupato a gestire migliaia e migliaia di domande al secondo ora deve perdere tempo a superare un indice non uniforme e fare la stessa cosa di nuovo sui joins (che è più lento di Seleziona regolarmente su una tabella non ottimizzata, prendi DW come esempio in cui ci sono possibili il più possibile per accelerare il recupero dei dati). Anche se usi anche UTF in grado di scherzare con il motore del database (ho visto alcuni casi).
Personalmente, dalla mia esperienza, un indice adeguatamente organizzato può aumentare la velocità di un join del ~ 70% e fare un join su una colonna interi può accelerare il join di quanto circa ~ 25% (a seconda di i dati). Poiché le tabelle principali iniziano a crescere e queste tabelle si abituano su di loro, preferiresti avere un tipo di dati intero occupare la colonna che ha alcuni byte vs aventi un campo Varchar / Char che occuperà più spazio. Si riduce a risparmiare sullo spazio su disco, aumentando le prestazioni e la struttura complessiva di un database relazionale.
Inoltre, come James Snell ha menzionato:
.Le chiavi primarie devono anche essere immutabili, qualcosa dei codici aeroportuali IATA non sono decisamente no. Possono essere cambiati al capriccio dell'IATA.
Così prendendo in considerazione questo, preferiresti aggiornare 1 record che è vincolato a un numero, vs dover aggiornare che un record più tutti i record nella tabella su cui si unisci a.
Se prendi l'approccio "Uso le chiavi surrogato tutto il tempo", arrivi a bypassare questo tipo di preoccupazione. Potrebbe non essere una buona cosa perché è importante dare dei tuoi dati un po 'di pensiero, ma certamente salva un sacco di tempo, engergy e sforzo. Se qualcuno dovesse adottare un'accezione a questa regola, gli esempi elencati si qualificano sicuramente perché ci vuole un vicino "atto del congresso" per rendere il cambiamento.
Le query ad hoc di un database con queste chiavi naturali sono certamente utili. Creare viste che fanno la stessa cosa includendo anche le tabelle di ricerca possono funzionare altrettanto bene. I database moderni fanno un lavoro molto migliore con questo tipo di roba fino al punto in cui probabilmente non importa.
Ci sono alcuni casi specifici per gli Stati Uniti, dove gli standard sono stati drasticamente modificati: Codice postale ampliato da 5 a 9 cifre, abbreviazioni statali ad una coerente 2 lettere e sbarazzarsi del periodo (ricorda quando illinois era ammalato.?), E la maggior parte del mondo ha avuto a che fare con Y2K. Se hai un'app in tempo reale con i dati diffusi in tutto il mondo che contengono miliardi di record, gli aggiornamenti a cascata non sono l'idea migliore, ma non dovremmo lavorare tutti in luoghi che affrontiamo tali sfide? Con quel dataset, potresti testarlo per te e trovare una risposta più diffinisteri.
