Ho valori di identificazione per i prodotti che ho bisogno di conservare. Al momento sono tutti interi, ma non sono sicuro che il fornitore di dati in futuro introdurrà lettere o simboli in quel mix, quindi sto discutendo se archiviarlo ora come intero o stringa.Eventuali svantaggi di memorizzare un numero intero come stringa in un database?
Ci sono prestazioni o altri svantaggi nel salvare i valori come stringhe?
A meno che non si abbia realmente bisogno delle funzionalità di un numero intero (vale a dire la possibilità di eseguire operazioni aritmetiche), è probabilmente meglio memorizzare gli ID di prodotto come stringhe. Non dovrai mai fare nulla come aggiungere due ID prodotto insieme o calcolare la media di un gruppo di ID prodotto, quindi non è necessario un tipo numerico effettivo.
È improbabile che la memorizzazione degli ID prodotto come stringhe causi una differenza misurabile nelle prestazioni. Mentre ci sarà un leggero aumento delle dimensioni dello storage, la dimensione di una stringa ID prodotto sarà probabilmente molto più piccola rispetto ai dati nel resto della riga del database.
La memorizzazione degli ID prodotto come stringhe ti farà risparmiare molto tempo in futuro se il fornitore di dati decide di iniziare a utilizzare caratteri alfabetici o di simboli. Non c'è un vero svantaggio.
I numeri interi sono più efficienti dal punto di vista dello storage e delle prestazioni. Tuttavia, se esiste una possibilità remota che possano essere introdotti caratteri alfa, è necessario utilizzare una stringa. A mio parere, i benefici in termini di efficienza e prestazioni sono probabilmente trascurabili, mentre il tempo necessario per modificare il codice potrebbe non esserlo.
Non sono sicuro di quanto siano validi i database per confrontare se una stringa è maggiore di un'altra, come con gli interi. Prova una query come questa:
SELECT * FROM my_table WHERE integer_as_string > '100';
database sono molto bravo in questo (tuttavia, useranno le regole di confronto di stringa invece di regole di confronto numerico). Ma quanto spesso vorrete confrontare gli ID dei prodotti come questo? –
Ogni volta che si ordina per numero di parte (ID prodotto) ... e questo è un problema se i dati sono attualmente presentati in ordine numerico e che cambia in ordine di stringa. –
tutto dipende da che tipo di id si sta parlando. Se si tratta di un codice come un numero di telefono, sarebbe meglio utilizzare un varchar per l'id e quindi avere il proprio ID come serial per il db e utilizzare per la chiave primaria. In un caso in cui il numero intero non ha valore numerico, i varchar sono generalmente preferiti.
+1 per raccomandare un PK intero se si converte in stringhe – colithium
come risposta a Integer vs String in database
Nel mio paese, post-codici sono anche sempre 4 cifre. Ma la prima cifra può essere zero.
Se si memorizza "0700" come un intero, è possibile ottenere un sacco di problemi:
Può essere letta come un valore ottale Se viene letto correttamente come un valore decimale, esso si eccita in "700" Quando si ottiene il valore "700", è necessario ricordare di aggiungere lo zero Non si aggiunge lo zero, in seguito, come saprai se "700" è "0700", o qualcuno ha fatto un errore di digitazione "7100"? Tecnicamente, i nostri codici postali sono stringhe reali, anche se sono sempre 4 cifre.
È possibile memorizzarli come numeri interi, per risparmiare spazio. Ma ricorda che questo è un semplice trucco per DB e fai attenzione a guidare gli zeri.
Ma per quanto riguarda la memorizzazione di quanti file sono in un torrent? Integer o stringa?
Questo è chiaramente un numero intero.
Se l'ID dovesse mai iniziare con zero, memorizzarlo come in interger.
-1: Gli zeri iniziali per i numeri interi sono una pessima idea in Python. 0900 è (eccezione Python 3.0) un errore di sintassi. Se ci sono degli zeri iniziali, DEVI usare una stringa. –
Sì, supponevo che joshhunt intendesse dire "Se l'ID dovesse mai iniziare con uno zero, memorizzarlo come stringa_stringa". L'ordinamento è un'altra considerazione con questa roba (anche menzionata su quel thread collegato). – cheduardo
NON prendere in considerazione le prestazioni. Considera il significato.
I "numeri" ID non sono numerici, tranne che sono scritti con un alfabeto di tutte le cifre.
Se ho il numero di parte 12 e il numero di parte 14, qual è la differenza tra i due? Il numero di parte 2 o -2 è significativo? No.
I numeri di parte (e tutto ciò che non ha unità di misura) non sono "numerici". Sono solo stringhe di cifre.
Codici postali negli Stati Uniti, ad esempio. Numeri di telefono. Numeri di previdenza sociale. Questi non sono numeri. Nella mia città la differenza tra il codice di avviamento postale 12345 e 12309 non è la distanza da casa mia al centro.
Non conflate i numeri - con unità - dove somme e differenze significa qualcosa di con stringhe di cifre senza somme o differenze.
I numeri ID parte sono - correttamente - stringhe. Non interi. Non saranno mai interi perché non hanno somme, differenze o medie.
La tua risposta è buona. Un pungolo: ci sono numeri in cui la somma non ha senso. Qual è la somma di due temperature? La differenza è ancora significativa. –
La somma di due temperature significa il doppio della loro temperatura media;) E se si usano i Kelvin, la somma indica la somma delle loro energie interne. – Kiv
@Walter Mitty: sei oh, quindi corretto nel localizzare il problema con qualsiasi misura che sia in realtà una media. Le medie (e altri campioni quantizzati di dati continui) sono ciò che le persone del data warehouse chiamano una dimensione "semi-additiva" - non sommano - ma fanno la media. Le dimensioni semi-additive (come la temperatura) sono ancora numeri. Gli ID non sono ancora numeri. –
Lo spazio occupato da un intero sarebbe molto meno di una stringa. Ad esempio 2^32-1 = 4,294,967,295. Ciò richiederebbe 10 byte per l'archiviazione, dove il numero intero richiederebbe 4 byte da memorizzare. Per una singola voce questo non è molto spazio, ma quando inizi a milioni ... Come molti altri post suggeriscono ci sono molti altri aspetti da considerare, ma questo è uno svantaggio della rappresentazione della stringa.
Ho appena trascorso l'ultimo anno a occuparmi di un database che ha quasi tutti gli ID come stringhe, alcuni con solo cifre e altri misti. Questi sono i problemi:
Ovviamente, se si esauriscono gli ID o non si sa come creare nuovi ID, l'app è morta. Suggerisco che se non riesci a controllare il formato dei tuoi ID in entrata, devi creare i tuoi ID (numerici) e mettere in relazione l'ID fornito dall'utente. È quindi possibile garantire che il proprio ID sia affidabile e univoco (e numerico), ma fornire un ID visualizzabile dall'utente che può avere qualsiasi formato desiderato dagli utenti e non deve nemmeno essere univoco in tutta l'app. Questo è più lavoro, ma se tu avessi passato quello che ho, sapresti quale strada seguire.
Anil G
D'altra in realtà dipende dalla tua situazione Se hai intenzione di memorizzare qualcosa come numeri di telefono o numeri di iscrizione, è perfettamente logico utilizzare le stringhe
Utilizzare ID indipendente e aggiungere ID stringa se necessario: se c'è un business indicatore che è necessario includere, perché renderlo ID di sistema?
Drawbac principale KS:
operazioni integer e indicizzazione sempre mostrano una migliore performance su larga scala di dati (più di 1k righe di una tabella, per non parlare di tabelle collegate)
Dovrete fare ulteriore controlla per limitare i valori solo numerici in una colonna: questi possono essere regex sia sul lato client che sul lato database. Ad ogni modo, dovrai garantire in qualche modo che ci sia in realtà un intero.
e si creerà strato contesto aggiuntivo per gli sviluppatori di conoscere, e in ogni caso sarà sempre qualcuno rovinare questo in su :)
+1 Esattamente quello che avrei detto. :) Utilizzare un tipo numerico solo se si memorizzano quantità o grandezze. – cheduardo
+1 Il punto è, l'ID è _conceptually_ non un numero, come evidenziato dalla possibilità di mischiare lettere con cifre. – Svante