Migliori pratiche per la memorizzazione di indirizzi postali in un database (RDBMS)?

Esistono buoni riferimenti per le migliori pratiche per la memorizzazione di indirizzi postali in un RDBMS? Sembra che ci siano un sacco di compromessi che possono essere fatti e molti pro e contro a ciascuno da valutare – sicuramente questo è stato fatto più e più volte? Forse qualcuno ha almeno scritto alcune lezioni apprese da qualche parte?

Gli esempi dei compromessi di cui sto parlando sono la memorizzazione dello zipcode come numero intero vs un campo char, il numero civico deve essere memorizzato come campo separato o parte della riga di indirizzo 1, se i numeri suite / appartamento / ecc devono essere normalizzati o semplicemente memorizzati come Pezzo di testo nella riga di indirizzo 2, come gestisci zip +4 (campi separati o un campo grande, intero vs testo)? eccetera.

Mi preoccupo principalmente degli indirizzi degli Stati Uniti a questo punto, ma immagino ci siano alcune buone pratiche per prepararsi all’eventualità di andare anche a livello globale (ad esempio denominare campi in modo appropriato come regione invece che stato o codice postale invece di codice postale, eccetera.

Per un uso più internazionale, uno schema da considerare è quello usato da Drupal Address Field . È basato sullo standard xNAL e sembra coprire la maggior parte dei casi internazionali. Un po ‘di ricerca di quel modulo rivelerà alcune belle perle per interpretare e convalidare gli indirizzi a livello internazionale. Ha anche un bel set di aree amministrative (provincia, stato, oblast, ecc.) Con codici ISO.

Ecco il succo dello schema, copiato dalla pagina del modulo:

country => Country (always required, 2 character ISO code) name_line => Full name (default name entry) first_name => First name last_name => Last name organisation_name => Company administrative_area => State / Province / Region (ISO code when available) sub_administrative_area => County / District (unused) locality => City / Town dependent_locality => Dependent locality (unused) postal_code => Postal code / ZIP Code thoroughfare => Street address premise => Apartment, Suite, Box number, etc. sub_premise => Sub premise (unused) 

Una lezione che ho imparato:

  • Non memorizzare nulla numericamente.
  • Paese del magazzino e area amministrativa come codici ISO, ove ansible.
  • Quando non lo sai, sii lassista riguardo ai campi obbligatori. Alcuni paesi potrebbero non utilizzare campi che diamo per scontati, anche cose di base come locality e thoroughfare .

In qualità di utente “internazionale”, non c’è nulla di più frustrante di gestire un sito web orientato solo verso indirizzi in formato USA. All’inizio è un po ‘scortese, ma diventa un problema serio quando la validazione è anche troppo zelante.

Se sei preoccupato di diventare globale, l’unico consiglio che ho è di mantenere le cose in forma libera. Paesi diversi hanno convenzioni diverse: in alcuni, il numero civico viene prima del nome della via, in alcuni viene dopo. Alcuni hanno stati, alcune regioni, alcune contee, alcune combinazioni di questi. Qui nel Regno Unito, il codice postale non è un codice postale, è un codice postale contenente sia lettere che numeri.

Suggerirei semplicemente ~ 10 linee di stringhe di lunghezza variabile, insieme a un campo separato per un codice postale (e attenzione a come lo descrivi per far fronte alle sensibilità nazionali). Consenti all’utente / cliente di decidere come scrivere i propri indirizzi.

Se hai bisogno di informazioni complete su come gli altri paesi usano gli indirizzi postali, ecco un link di riferimento molto buono (Columbia University):

Frank’s Compulsive Guide to Postal Addresses
Indirizzamento efficace per posta internazionale

Dovresti assolutamente considerare di memorizzare il numero civico come un campo di carattere piuttosto che un numero, a causa di casi speciali come “mezzi numeri” o il mio indirizzo attuale, che è qualcosa come “129A” ​​- ma l’A non è considerato un appartamento numero per i servizi di consegna.

Ho fatto questo (rigorosamente modello di strutture di indirizzi in un database), e non lo farei mai più. Non puoi immaginare quanto siano pazzesche le eccezioni che dovrai prendere in considerazione di norma.

Ricordo vagamente qualche problema con i codici postali norvegesi (credo), che erano tutte e 4 le posizioni, ad eccezione di Oslo, che ne aveva circa 18.

Sono sicuro che dal momento in cui abbiamo iniziato a utilizzare i codici postali geograficamente corretti per tutti i nostri indirizzi nazionali, molte persone hanno iniziato a lamentarsi del fatto che la loro posta arrivasse troppo tardi. Risultò che quelle persone vivevano vicino a una linea di demarcazione tra le aree postali, e nonostante il fatto che qualcuno abitasse davvero in un’area postale, diciamo, 1600, in realtà la sua posta doveva essere indirizzata alla posta 1610, perché in realtà era quella della vicina area postale che in realtà lo serviva, quindi spedire la sua posta alla sua corretta area postale avrebbe preso quella mail un paio di giorni in più per arrivare, a causa dell’intervento indesiderato che era richiesto nel corretto ufficio postale per inoltrarlo all’area postale sbagliata …

(Alla fine abbiamo registrato quelle persone con un indirizzo all’estero nel paese con codice ISO “ZZ”.)

A meno che tu non abbia intenzione di fare matematica sui numeri civici o sui codici postali / postali, stai solo invitando il dolore futuro memorandoli come numeri.

Potresti risparmiare qualche byte qua e là e magari ottenere un indice più veloce, ma che cosa fai quando gli Stati Uniti postali, o qualunque altro paese con cui stai trattando, decide di introdurre l’alfa nei codici?

Il costo dello spazio su disco sarà molto più economico del costo di ripararlo più tardi … y2k qualcuno?

Dovresti certamente consultare ” È un buon modo per modellare le informazioni sugli indirizzi in un database relazionale “, ma la tua domanda non è un duplicato diretto di ciò.

Ci sono sicuramente molte risposte preesistenti (per esempio, guarda i modelli di dati di esempio su DatabaseAnswers ). Molte delle risposte preesistenti sono difettose in alcune circostanze (non si parla affatto di risposte DB).

Uno dei principali problemi da considerare è la portata degli indirizzi. Se il tuo database deve trattare con indirizzi internazionali, devi essere più flessibile rispetto a quando devi gestire gli indirizzi in un solo paese.

A mio avviso, è spesso (cosa che non significa sempre ) ragionevole sia per registrare l’immagine dell’etichetta dell’indirizzo che per analizzare separatamente il contenuto. Ciò consente di gestire le differenze tra il posizionamento dei codici postali, ad esempio, tra paesi diversi. Certo, puoi scrivere un analizzatore e un formattatore che gestiscono le eccentricità di diversi paesi (ad esempio, gli indirizzi degli Stati Uniti hanno 2 o 3 linee, al contrario, gli indirizzi britannici possono avere molto di più, un indirizzo che scrivo periodicamente ha 9 righe). Ma può essere più facile avere gli umani che fanno l’analisi e la formattazione e lasciare che il DBMS memorizzi semplicemente i dati.

Aggiungendo a ciò che hanno detto @ Jonathan Leffler e @ Paul Fisher

Se si prevede di avere degli indirizzi postali per il Canada o il Messico aggiunti alle proprie esigenze, memorizzare postal-code come stringa è obbligatorio. Il Canada ha codici postali alfanumerici e non ricordo quale sia l’aspetto del Messico fuori dalla mia testa.

Ho trovato che elencare tutti i campi possibili dalla più piccola unità discreta alla più grande è il modo più semplice. Gli utenti compileranno i campi che ritengono adatti. La mia tabella degli indirizzi ha questo aspetto:

 ********************************* Field Type ********************************* address_id (PK) int unit string building string street string city string region string country string address_code string ********************************* 

Dov’è il “trade off” nella memorizzazione dello ZIP come NUMERO o VARCHAR? Questa è solo una scelta – non è un compromesso a meno che non ci siano benefici per entrambi e devi rinunciare ad alcuni benefici per ottenere gli altri.

A meno che la sum delle cerniere non abbia alcun significato, le cerniere come numero non sono utili.

Questo potrebbe essere eccessivo, ma se hai bisogno di una soluzione che funzioni con più paesi e hai bisogno di elaborare in modo programmatico parti dell’indirizzo:

è ansible avere una gestione di indirizzi specifici per paese utilizzando due tabelle: una tabella generica con 10 colonne VARCHAR2, 10 colonne Number, un’altra tabella che associa questi campi ai prompt e una colonna di paese che lega una struttura di indirizzi a un paese.

Se dovessi verificare un indirizzo o utilizzarlo per elaborare i pagamenti con carta di credito, avrai almeno bisogno di una piccola struttura. Un blocco di testo in formato libero non funziona molto bene per questo.

Il codice postale è un campo facoltativo comune per la convalida delle transazioni con carta di pagamento senza utilizzare l’intero indirizzo. Quindi avere un campo separato e generosamente dimensionato per quello (almeno 10 caratteri).

Ispirato alle Risposte del Database

 Line1 Line2 Line3 City Country_Province PostalCode CountryId OtherDetails 

Vorrei semplicemente mettere tutti i campi insieme in un grande campo NVARCHAR (1000), con un elemento textarea per l’utente per inserire il valore per (a meno che non si desidera eseguire analisi su codici zip ad esempio). Tutti gli ingressi di indirizzo linea 1, indirizzo linea 2, ecc. Sono così fastidiosi se hai un indirizzo che non si adatta bene a quel formato (e, sai, ci sono altri paesi oltre gli Stati Uniti).