Migliori pratiche per memorizzare gli indirizzi postali in un database (RDBMS)?

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

Esempi di compromessi di cui sto parlando sono la memorizzazione del codice postale come numero intero rispetto a un campo char, se il numero civico deve essere memorizzato come campo separato o parte della riga dell'indirizzo 1, se i numeri di suite / appartamento / ecc. Devono essere normalizzati o semplicemente memorizzati come un pezzo di testo nella riga indirizzo 2, come gestisci zip +4 (campi separati o un campo grande, numero intero vs testo)? eccetera.

Mi occupo principalmente degli indirizzi degli Stati Uniti a questo punto, ma immagino che ci siano alcune best practice per quanto riguarda la preparazione per l'eventualità di diventare anche globali (ad es. Denominare i campi in modo appropriato come regione invece di stato o codice postale invece di codice postale, eccetera.

Per un utilizzo più internazionale, uno schema da considerare è quello utilizzato da Drupal Address Field . È basato sullo standard xNAL e sembra coprire la maggior parte dei casi internazionali. Un po 'di approfondimento in quel modulo rivelerà alcune belle perle per interpretare e convalidare 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.
• Memorizza il paese e l'area amministrativa come codici ISO ove possibile.
• Quando non lo sai, sii rilassato nel richiedere campi. Alcuni paesi potrebbero non utilizzare campi che dai per scontati, anche cose di base come locality& thoroughfare.

In quanto utente "internazionale", non c'è niente di più frustrante che avere a che fare con un sito web orientato esclusivamente agli indirizzi in formato USA. All'inizio è un po 'scortese, ma diventa un problema serio quando la convalida è 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 strada, in altri 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.

Consiglierei semplicemente ~ 10 righe di stringhe di lunghezza variabile, insieme a un campo separato per un codice postale (e fai attenzione a come lo descrivi per far fronte alle sensibilità nazionali). Lascia che l'utente / cliente decida come scrivere i propri indirizzi.

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

Frank's Compulsive Guide to Postal Address Indirizzi
efficaci per la posta internazionale

Dovresti assolutamente considerare di memorizzare il numero civico come un campo di caratteri piuttosto che come un numero, a causa di casi speciali come "mezzi numeri" o il mio indirizzo attuale, che è qualcosa come "129A", ma la A non è considerata un appartamento numero per i servizi di consegna.

L'ho fatto (rigorosamente modella le strutture degli indirizzi in un database) e non lo rifarei mai più. Non puoi immaginare quanto siano folli le eccezioni che dovrai tenere in considerazione di regola.

Ricordo vagamente qualche problema con i codici postali norvegesi (credo), che erano tutte e 4 le posizioni, tranne Oslo, che ne aveva 18 o giù di lì.

Sono assolutamente 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 fosse arrivata troppo tardi. Si è scoperto che quelle persone vivevano vicino al confine tra le aree postali, e nonostante qualcuno vivesse davvero nell'area postale, diciamo 1600, in realtà la sua posta dovrebbe essere indirizzata all'area postale 1610, perché in realtà era quella vicina area postale che effettivamente gli è servito, quindi inviare la sua posta alla sua area postale corretta richiederebbe un paio di giorni in più per arrivare a quella posta, a causa dell'intervento indesiderato che era richiesto nell'ufficio postale corretto per inoltrarla all'area postale errata ...

(Abbiamo finito per registrare quelle persone con un indirizzo all'estero nel paese con il codice ISO "ZZ".)

Dovresti certamente consultare " Questo è un buon modo per modellare le informazioni sugli indirizzi in un database relazionale ", ma la tua domanda non è un duplicato diretto di questo.

Ci sono sicuramente molte risposte preesistenti (controlla i modelli di dati di esempio su DatabaseAnswers , per esempio). Molte delle risposte preesistenti sono difettose in alcune circostanze (non prendono affatto in considerazione DB Answers).

Uno dei problemi principali da considerare è l'ambito degli indirizzi. Se il tuo database deve gestire indirizzi internazionali, devi essere più flessibile che se dovessi trattare solo indirizzi in un paese.

A mio avviso, è spesso (il che non significa sempre ) sensato sia registrare l '"immagine dell'etichetta dell'indirizzo" dell'indirizzo e 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 gestiscano le eccentricità di diversi paesi (ad esempio, gli indirizzi degli Stati Uniti hanno 2 o 3 righe; al contrario, gli indirizzi britannici possono averne molto di più; un indirizzo a cui scrivo periodicamente ha 9 righe). Ma può essere più semplice fare in modo che gli umani eseguano l'analisi e la formattazione e che il DBMS memorizzi i dati.

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

Potresti salvare qualche byte qua e là, e magari ottenere un indice più veloce, ma cosa fai quando le poste americane, o qualunque altro paese con cui hai a che fare, decidono di introdurre alfa nei codici?

Il costo dello spazio su disco sarà molto più economico del costo per ripararlo in seguito ... y2k qualcuno?

In aggiunta a quanto hanno detto @ Jonathan Leffler e @ Paul Fisher

Se prevedi di aggiungere indirizzi postali per il Canada o il Messico alle tue esigenze, l'archiviazione postal-codecome stringa è un must. Il Canada ha codici postali alfanumerici e non ricordo che aspetto abbia il Messico dalla parte superiore della mia testa.

Ho scoperto che elencare tutti i campi possibili dalla più piccola unità discreta alla più grande è il modo più semplice. Gli utenti riempiranno i campi che ritengono opportuni. 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 "compromesso" nell'archiviare lo ZIP come NUMERO o VARCHAR? Questa è solo una scelta - non è un compromesso a meno che non ci siano vantaggi per entrambi e devi rinunciare ad alcuni vantaggi per ottenerne altri.

A meno che la somma delle zip non abbia alcun significato, Zips as number non è utile.

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

potresti avere la gestione degli indirizzi specifici per paese utilizzando due tabelle: una tabella generica con 10 colonne VARCHAR2, 10 colonne numeriche, un'altra tabella che mappa questi campi ai prompt e ha una colonna del paese che lega una struttura di indirizzi a un paese.

Se devi verificare un indirizzo o utilizzarlo per elaborare 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 crea un campo separato e di dimensioni generose per quello (almeno 10 caratteri).

Ispirato da Database Answers

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Vorrei solo mettere tutti i campi insieme in un grande campo NVARCHAR (1000), con un elemento textarea per l'utente per inserire il valore (a meno che non si desideri eseguire analisi su, ad esempio, codici di avviamento postale). Tutti quegli input della riga dell'indirizzo 1, della riga dell'indirizzo 2, ecc. Sono così fastidiosi se hai un indirizzo che non si adatta bene a quel formato (e, sai, ci sono altri paesi oltre agli Stati Uniti).