Domanda

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

Le zip statunitensi sono 9.

Il canadese ha 7.

Penso che 32 caratteri rappresenterebbero un limite superiore ragionevole

Cosa mi sto perdendo?

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

È stato utile?

Soluzione

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

Altri suggerimenti

Come già accennato da @ neil-mcguigan, wikipedia ha una pagina decente sull'argomento. Sulla base di questi 12 caratteri dovrebbe 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.

Perché dovresti dichiarare una dimensione del campo maggiore dei dati reali che ti aspetti di memorizzarvi?

Se la versione iniziale della tua applicazione supporterà gli indirizzi degli Stati Uniti e del Canada (che desidero dedurre dal fatto che tu 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 post che altri hanno fatto ai codici postali in diversi paesi, VARCHAR2 (9) o VARCHAR2 (10) sarebbero sufficienti per la maggior parte se non per tutti gli altri paesi.

Lungo la linea, puoi sempre ALTERARE 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 un altro (ovvero perché desiderano un'altra riga su un'etichetta di spedizione). Devi anche occuparti del test dei casi limite (ogni applicazione che visualizza un ZIP gestirà 50 caratteri?). E con il fatto che quando i client recuperano i dati dal database, generalmente 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.

A parte, potresti anche considerare di memorizzare (almeno per gli indirizzi statunitensi) il codice postale e l'estensione +4 separatamente. In genere è utile essere in grado di generare report per area geografica e spesso potresti voler mettere insieme tutto in un codice postale anziché scomporlo per l'estensione +4. A quel punto, è utile non cercare di SUBSTR per inserire i primi 5 caratteri per il codice postale.

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

Se non hai davvero bisogno di LAVORO con un codice postale, suggerirei di non preoccuparti. Per lavoro, intendo eseguire un'elaborazione speciale anziché semplicemente utilizzare per stampare etichette di indirizzi e così via.

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

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

La normalizzazione? I codici postali potrebbero essere utilizzati più di una volta e potrebbero essere correlati a nomi di strade o nomi di città. Tabella / i separata / e.

I codici postali canadesi hanno solo 6 caratteri, sotto forma di lettere e numeri (LNL NLN)

Il Regno Unito ha pubblicato gli standard: Catalogo delle norme sui dati del governo del Regno Unito

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 

Se vuoi integrare i codici postali nel database, è meglio usare il database dei geonames. Anche se è difficile da usare e capire, ma è il più grande database geografico disponibile gratuitamente per gli utenti come noi.

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

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top