Devo memorizzare i codici postali in un database. Quanto dovrebbe essere grande la colonna?

103

Mi aspetto che la colonna sia un VARCHAR2, nel mio database Oracle.

Le zip degli Stati Uniti sono 9.

Il canadese ha 7 anni.

Penso che 32 caratteri sarebbero un limite superiore ragionevole

Cosa mi sto perdendo?

[EDIT] TIL: 12 è una risposta ragionevole alla domanda Grazie a tutti coloro che hanno contribuito.

— EvilTeach
fonte

Link utile, tuttavia la sua precisione potrebbe essere un po 'fuori luogo. Ad esempio, elenca i codici postali australiani come 7 caratteri, quando in realtà sono 4. Rif: en.wikipedia.org/wiki/Postcodes_in_Australia e l'elenco dei codici postali disponibile su www1.auspost.com.au/postcodes .

— rossp

re: il mio commento precedente - ciò non significa che questo elenco non sia utile come guida. Supponendo che la lista sbagli sul lato dei codici postali più lunghi, la lunghezza massima è di 9 caratteri, quindi 16 caratteri o giù di lì dovrebbero darti molto spazio per respirare.

— rossp

Anche l'elenco dei paesi è un po 'corto. Sono sicuro che ci sono più paesi sul pianeta di quelli elencati ...

— Robert Koritnik

2

Secondo en.wikipedia.org/wiki/List_of_postal_codes , il più lungo è 12 caratteri, se stai memorizzando il '-', altrimenti 11

— Neil McGuigan

@CMS: potresti voler aggiornare il link a questa pagina di wikipedia , sembra che sia più dettagliato.

— Vajk Hermecz

51

Scorrendo la pagina dei codici postali di Wikipedia , 32 caratteri dovrebbero essere più che sufficienti. Direi che anche 16 caratteri sono buoni.

— strager
fonte

8

Buon collegamento. Anche tenendo conto della punteggiatura in US ZIP + 4, 10 caratteri sarebbero sufficienti per qualsiasi paese per quanto ne so.

— Jonathan Leffler

Sulla base di questo collegamento, dalla pagina collegata sopra, andrei con 18 per ospitare paesi come il Cile: en.wikipedia.org/wiki/List_of_postal_codes

— mopo922

5

Il Cile è di 7 caratteri. La pagina web a cui hai fatto riferimento mostra semplicemente la varianza della punteggiatura.

— EvilTeach

21

Come già sollevato da @ neil-mcguigan, wikipedia ha una pagina decente sull'argomento. Sulla base di questo 12 caratteri dovrebbero farlo: http://en.wikipedia.org/wiki/List_of_postal_codes

L'articolo di wikipedia elenca ~ 254 paesi, il che è abbastanza buono per quanto riguarda UPU (Universal Postal Union) ha 192 paesi membri.

— Vajk Hermecz
fonte

2

Nota che Montserrat ha solo 8 caratteri, 1110-1350 indica un intervallo. discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz

Forse Wikipedia necessita di modifiche, dal momento che il codice postale dall'aspetto simile per Malta ha uno generico come "AAA NNNN". Non mi dispiacerebbe avere anche 15 caratteri perché potrebbe essere un problema minore in seguito se dobbiamo regolare la lunghezza della colonna, anche con un uso corretto dei tipi di dati, non dovrebbero comunque prendere tutti i 15 caratteri (possibilmente varchar o nvarchar o simili?) .

— Manohar Reddy Poreddy

12

Perché dichiarare una dimensione del campo maggiore dei dati effettivi che ci si aspetta di memorizzare in esso?

Se la versione iniziale della tua applicazione supporterà gli indirizzi statunitensi e canadesi (che deduco dal fatto che chiami quelle dimensioni nella tua domanda), dichiarerei il campo come VARCHAR2 (9) (o VARCHAR2 ( 10) se si intende memorizzare il trattino nei campi ZIP + 4). Anche guardando i messaggi che altri hanno scritto ai codici postali di diversi paesi, VARCHAR2 (9) o VARCHAR2 (10) sarebbe sufficiente per la maggior parte, se non per tutti gli altri paesi.

In fondo alla linea, puoi sempre ALTER la colonna per aumentare la lunghezza in caso di necessità. Ma generalmente è difficile impedire a qualcuno, da qualche parte, di decidere di diventare "creativo" e inserire 50 caratteri in un campo VARCHAR2 (50) per un motivo o per l'altro (cioè perché vogliono un'altra riga su un'etichetta di spedizione). Devi anche occuparti del test dei casi limite (ogni applicazione che visualizza uno ZIP gestirà 50 caratteri?). E con il fatto che quando i client recuperano dati dal database, in genere allocano la memoria in base alla dimensione massima dei dati che verranno recuperati, non alla lunghezza effettiva di una determinata riga. Probabilmente non è un grosso problema in questo caso specifico, ma 40 byte per riga potrebbero essere un discreto pezzo di RAM per alcune situazioni.

Per inciso, potresti anche considerare di memorizzare (almeno per gli indirizzi statunitensi) il codice postale e l'estensione +4 separatamente. Generalmente è utile essere in grado di generare rapporti per regione geografica e spesso potresti voler mettere tutto in un codice postale insieme piuttosto che scomporlo dall'estensione +4. A quel punto, è utile non dover provare a SUBSTR fuori i primi 5 caratteri per il codice postale.

— Justin Cave
fonte

4

Bene, supponendo che stiamo codificando in qualcosa di sciocco come Pro * C, avere il campo abbastanza grande per la crescita significa che il codice non dovrà essere toccato se l'uso aumenta.

— EvilTeach

Sì, può avere senso suddividere il codice postale degli Stati Uniti in 5 e 4 cifre, a seconda di cosa si intende utilizzarlo. Ad esempio, se stai eseguendo una sorta di corrispondenza degli indirizzi, potresti voler abbinare prima lo zip5 e risolvere situazioni ambigue con lo zip 9. Aiuta anche a usare un codice paese

— EvilTeach

3

Quello che ti manca è un motivo per cui hai bisogno che il codice postale venga gestito in modo speciale.

Se non hai davvero bisogno di LAVORARE con un codice postale, ti suggerisco di non preoccupartene. Per lavoro, intendo eseguire un'elaborazione speciale piuttosto che utilizzare solo per stampare etichette per indirizzi e così via.

Crea semplicemente tre o quattro campi indirizzo di VARCHAR2 (50) [per esempio] e lascia che l'utente inserisca quello che vuole.

Hai davvero bisogno di raggruppare i tuoi ordini o transazioni per codice postale? Penso di no, dal momento che diversi paesi hanno schemi molto diversi per questo campo.

— paxdiablo
fonte

Sono d'accordo. Utilizzando un campo VARCHAR2 la realtà è che per un campo come il codice postale non importa. Un po 'troppo grande è meglio che infastidire un cliente perché non può inserire i propri dettagli.

— Toby Allen,

E i varchar sono utili poiché i database (almeno DB2) possono ottimizzarne l'archiviazione, in modo da non sprecare spazio di archiviazione.

— paxdiablo

1

si sottolinea che l'ordinamento per paese e codice postale si tradurrà in tariffe postali più economiche in alcuni luoghi.

— EvilTeach

10

Disgaree. A un certo punto deciderai che dovrai convalidare gli indirizzi nel tuo database (ad es. Per correggere errori tipografici e di immissione dei dati) ed è allora che troverai il vantaggio di costruire correttamente il tuo modello di dati piuttosto che semplicemente inserire tutto secchi.

— Gary Myers

1

@Pax Se si consegna la posta in blocco alla Royal Mail preselezionata dal distretto principale (prima lettera / due lettere) del codice postale, è possibile farla recapitare tramite MailSort, che è più economica della normale posta di seconda classe. Questo è solo un esempio.

— Richard Gadsden

3

Normalizzazione? I codici postali potrebbero essere utilizzati più di una volta e potrebbero essere correlati ai nomi delle vie o delle città. Tavoli separati.

— Stephan Eggermont
fonte

Interessante. Un punto di vista diverso semplicemente sottovalutato senza motivo. +1

— EvilTeach

Un codice postale in genere fa riferimento a un blocco su un lato della strada. Per trovare una regione più ampia, seleziona la prima metà del codice postale. Avere queste informazioni in una tabella separata non aiuta davvero nulla e sarebbe più complicato da mantenere.

— RevNoah

4

@EvilTeach: Scommetto che è stato downvoted perché è fuori tema. Ti dice quanto dovrebbe essere grande una colonna per memorizzare ogni possibile codice postale nel mondo? No.

— wmax

2

I codici postali canadesi sono composti da soli 6 caratteri, sotto forma di lettere e numeri (LNLNLN)

— tegbains
fonte

3

I codici postali canadesi hanno uno spazio vuoto nel mezzo "ANA NAN", cioè 7 caratteri.

— EvilTeach

1

Ma lo spazio è sempre al centro, quindi non è necessario riporlo.

— Graeme Perrow

1

Lo spazio non sembra far parte dei dati: "Nota: i codici postali canadesi sono sempre formattati nella stessa sequenza: caratteri alfabetici / numerali / alfabetici / numerici / alfabetici / numerici (ad esempio K1A0B1)." È tratto dal sito web del Canada Post.

— tegbains il

2

Non credo che omettere lo spazio abbia nulla a che fare con la "normalizzazione". È solo un problema di visualizzazione. Come i trattini nei numeri di conto. Non lo memorizzerei e non ci farei affidamento per identificare i codici postali canadesi rispetto a un campo CountryCode (int) che può essere indicizzato. Separare i livelli di dati e presentazione è il modo giusto per farlo.

— Sam

2

Canada Post preferisce lo spazio nel codice postale quando si indirizzano le buste. È meglio memorizzarlo con lo spazio e gestire la convalida all'ingresso.

— RevNoah

2

Il Regno Unito ha pubblicato degli standard: UK Government Data Standards Catalog

Max 35 characters per line

Indirizzo postale internazionale:

Minimum of 2 lines and maximum of 5 lines for the postal delivery point 
details, plus 1 line for country and 1 line for postcode/zip code

La lunghezza del codice postale del Regno Unito è:

Minimum 6 and Maximum 8 characters

— PodTech.io
fonte

1

Se si desidera integrare i codici postali nel database, è meglio utilizzare il database dei nomi geografici. Anche se è difficile da usare e da capire, è il più grande database geografico disponibile gratuitamente per utenti come noi.

È più o meno probabile che tutti gli altri database di questo tipo abbiano gli stessi dati e la stessa struttura. Rimuovono solo alcune informazioni extra / ridondanti dal database. Se lo fai solo per sistemi a basso carico, usa i loro servizi gratuiti, i limiti sono attraenti e fornisce un'interfaccia più semplice usando json e ajax. Puoi visualizzare i limiti qui

Per tua informazione varchar (20) è sufficiente per memorizzare i codici postali

— Jay Kapasi
fonte