Dipende dal tuo motore. La saggezza comune è che le letture sono economiche, pochi byte qui e non avranno un impatto significativo sulle prestazioni di un database di dimensioni medio-piccole.
Ancora più importante, dipende dagli usi ai quali verrà inserita la chiave primaria. I periodici interi hanno il vantaggio di essere semplici da usare e da implementare. Inoltre, a seconda dell'implementazione specifica del metodo di serializzazione, hanno il vantaggio di essere rapidamente derivabili, poiché la maggior parte dei database memorizza semplicemente il numero seriale in una posizione fissa, anziché derivarlo Select max(ID)+1 from fooal volo.
La domanda diventa: in che modo una chiave di 5 caratteri presenta un "valore significativo" per te e per l'applicazione? Come viene creato questo valore e richiede più o meno tempo rispetto alla ricerca di un numero seriale incrementale. Mentre c'è una quantità banale di spazio risparmiato in alcuni numeri interi, la stragrande maggioranza dei sistemi ignorerà questo risparmio di spazio.
Non ci sono implicazioni in termini di prestazioni, a parte il fatto che la combinazione di caratteri richiede che non ci sia mai un motore automatico, poiché le tue "chiavi" non sono accettabili. Per il tuo dominio specifico, non preoccuparti delle chiavi artificiali e usa solo cinese, giapponese e tailandese come nomi di chiavi. Sebbene non sia possibile garantire l'unicità rispetto a qualsiasi possibile applicazione, nel proprio ambito è molto più ragionevole utilizzarli al posto di abbreviazioni orribili e forzate di 5 caratteri. Non ci sono impatti significativi sulle prestazioni finché non si arriva a milioni di tuple.
In alternativa, se stai solo monitorando per paese di origine e non specifiche cucine regionali (cantonese, sichuan, siciliano, umbro, calabrese, yucatecan, Oaxacan, ecc.), Puoi sempre utilizzare solo i codici ISO 3166 .
Se ho 10.000 ricette, la differenza tra una chiave di 5 caratteri e 20 caratteri non inizia a sommare?
Lo spazio è economico . Quando stai parlando di 10.000.000 di ricette su cui stai eseguendo operazioni OLAP, allora, forse. Con 10k ricette, stai guardando 150k di spazio.
Ma di nuovo dipende. Se hai molti milioni di dischi e ti stai unendo, allora ha senso denormalizzare la ricerca di qualcosa di così banale (in una visione materializzata). Per tutti gli scopi pratici, l'efficienza relativa del join su una macchina moderna tra una chiave a 5 caratteri e una chiave a lunghezza variabile è così simile da essere identica. Fortunatamente, viviamo in un mondo di CPU abbondante e disco abbondante. Quelli cattivi sono troppi join e inefficienza delle query, piuttosto che un confronto carattere per carattere. Detto questo, prova sempre .
Le cose P&T di questo livello sono così dipendenti dal database che le generalizzazioni sono estremamente difficili. Costruisci due modelli di esempio del database, popolali con il numero stimato di record, quindi vedi quale è più veloce. Nella mia esperienza, la lunghezza dei caratteri non fa una differenza enorme rispetto a buoni indici, buone configurazioni di memoria e altri elementi critici di ottimizzazione delle prestazioni.