Best practice per l'archiviazione coerente e completa degli indirizzi in un database [chiuso]

https://stackoverflow.com/questions/126207

02-07-2019
|

Domanda

Esistono best practice (o persino standard) per archiviare gli indirizzi in modo coerente e completo in un database?

Per essere più specifici, credo in questa fase che ci siano due casi per la memorizzazione degli indirizzi:

devi solo associare un indirizzo a una persona, un edificio o qualsiasi oggetto (il caso più comune). Quindi è probabilmente sufficiente una tabella piatta con colonne di testo (indirizzo1, indirizzo2, zip, città). Non è questo il caso che mi interessa.
vuoi eseguire statistiche sui tuoi indirizzi: quanti elementi in una determinata strada, città o ... Quindi vuoi evitare errori di ortografia di qualsiasi tipo e assicurarti coerenza. La mia domanda riguarda le migliori pratiche in questo caso specifico: quali sono i modi migliori per modellare un database di indirizzi coerente?

Una progettazione / soluzione specifica per paese sarebbe un ottimo inizio.

RISPOSTA : sembra che non esista ancora una risposta perfetta a questa domanda, ma:

xAL , come suggerito da Hank , è la cosa più vicina a un standard globale che è emerso. Sembra essere piuttosto esagerato, e non sono sicuro che molte persone vorrebbero implementarlo nel loro database ...
Per iniziare il proprio progetto (per un paese specifico), link di Dave al Universal Postal Union (UPU) è un ottimo punto di partenza.

Per quanto riguarda la Francia, esiste una norma (non ufficiale, ma di fatto standard) per gli indirizzi, che porta il bel nome di AFNOR XP Z10-011 (solo in francese), e deve essere pagato. La descrizione UPU per la Francia si basa su questa norma.
Mi è capitato di trovare la norma equivalente per la Svezia: SS 613401 .
A livello europeo, sono stati fatti alcuni sforzi, risultando nella norma EN 14142-1. È ottenibile tramite Membri nazionali CEN .

Soluzione

Userei una tabella Address , come hai suggerito, e la baserei sui dati tracciati da xAL .

Altri suggerimenti

Ci ho pensato anche io. Qui sono i miei pensieri lenti finora e mi chiedo cosa pensano gli altri.

xAL (e sua sorella che include nomi personali, XNAL) viene utilizzato da Google e dai servizi di geocodifica di Yahoo, dandogli un certo peso. Ma poiché lo stesso indirizzo può essere descritto in xAL in molti modi diversi - alcuni più specifici di altri - non vedo come xAL stesso sia un formato accettabile per l'archiviazione dei dati. Alcuni dei suoi nomi di campo potrebbero essere utilizzati, tuttavia, ma in realtà l'unico formato di base che può essere utilizzato tra i 16 paesi in cui la mia azienda spedisce è il seguente:


enum address-fields 
{
    name,
    company-name,
    street-lines[], // up to 4 free-type street lines
    county/sublocality,
    city/town/district,
    state/province/region/territory,
    postal-code,
    country
}

È abbastanza facile mappare in una singola tabella di database, consentendo solo NULL sulla maggior parte delle colonne. E sembra che sia così che Amazon e molte organizzazioni memorizzino effettivamente i dati degli indirizzi. Quindi la domanda che rimane è come dovrei modellarlo in un modello a oggetti che può essere facilmente utilizzato dai programmatori e da qualsiasi codice GUI. Abbiamo un tipo Indirizzo di base con sottoclassi per ogni tipo di indirizzo, come AmericanAddress , CanadianAddress , GermanAddress , e così via? Ognuno di questi tipi di indirizzo saprebbe formattare se stesso e opzionalmente potrebbe conoscere un po 'la convalida dei campi.

Potrebbero anche restituire alcuni tipi di metadati su ciascuno dei campi, come la seguente struttura di dati pseudocodici:


structure address-field-metadata 
{
    field-number,     // corresponds to the enumeration above
    field-index,      // the order in which the field is usually displayed
    field-name,       // a "localized" name; US == "State", CA == "Province", etc
    is-applicable,    // whether or not the field is even looked at / valid
    is-required,      // whether or not the field is required
    validation-regex, // an optional regex to apply against the field
    allowed-values[]  // an optional array of specific values the field can be set to
}

In effetti, invece di avere singoli oggetti indirizzo per ogni paese, potremmo adottare l'approccio leggermente meno orientato agli oggetti di avere un oggetto Address che evita le proprietà di .NET e usa un AddressStrategy per determinare le regole di formattazione e convalida:


object address
{
    set-field(field-number, field-value),
    address-strategy
}

object address-strategy
{
    validate-field(field-number, field-value),
    cleanse-address(address),
    format-address(address, formatting-options)
}

Quando si imposta un campo, quell'oggetto Address invoca il metodo appropriato sul suo oggetto AddressStrategy interno.

Il motivo dell'uso dell'approccio del metodo SetField () piuttosto che delle proprietà con getter e setter è che è più facile per il codice impostare effettivamente questi campi in modo generico senza ricorrere a reflection o switch dichiarazioni.

Puoi immaginare che il processo proceda in questo modo:

Il codice GUI chiama un metodo di fabbrica o alcuni di questi per creare un indirizzo basato su un paese. (Il menu a discesa del Paese, quindi, è la prima cosa che il cliente seleziona o ha una buona supposizione preselezionata per loro in base alle informazioni sulla cultura o all'indirizzo IP.)
La GUI chiama address.GetMetadata () o un metodo simile e riceve un elenco delle strutture AddressFieldMetadata come descritto sopra. Può usare questi metadati per determinare quali campi visualizzare (ignorando quelli con è applicabile impostato su false ), cosa etichettare quei campi (usando il campo - nome ), visualizza quei campi in un ordine particolare ed esegue una convalida a livello di presentazione su quei dati (usando il è richiesto , validation-regex e valori consentiti ).
La GUI chiama il metodo address.SetField () utilizzando il campo-numero (che corrisponde all'enumerazione sopra) e i relativi valori. L'oggetto Address o la sua strategia possono quindi eseguire alcune convalide avanzate dell'indirizzo su tali campi, invocare i programmi di pulizia degli indirizzi, ecc.

Potrebbero esserci lievi variazioni su quanto sopra se vogliamo che l'oggetto Address stesso si comporti come un oggetto immutabile una volta creato. (Cosa che probabilmente proverò a fare, poiché l'oggetto Address è molto più simile a una struttura di dati e probabilmente non avrà mai un comportamento reale associato a se stesso.)

Qualcuno di questi ha senso? Mi sto allontanando troppo dal percorso OOP? Per me, questo rappresenta un compromesso abbastanza sensato tra l'essere così astratti che l'implementazione è quasi impossibile (xAL) rispetto all'essere rigorosamente di parte negli Stati Uniti.

Aggiornamento 2 anni dopo: alla fine ho finito con un sistema simile a questo e ne ho scritto a il mio blog defunto .

Penso che questa soluzione sia il giusto equilibrio tra dati legacy e archiviazione dei dati relazionali, almeno per il mondo dell'e-commerce.

Nel Regno Unito esiste un prodotto chiamato PAF di Royal Mail

Questo ti dà una chiave univoca per indirizzo - ci sono dei cerchi da saltare, però.

Fondamentalmente vedo 2 scelte se vuoi coerenza:

Pulizia dei dati
Ricerche nella tabella dei dati di base

Annuncio 1. Lavoro con il sistema SAS e SAS Institute offre uno strumento per la pulizia dei dati, che in pratica esegue alcuni controlli e convalide sui tuoi dati e suggerisce che "Abram Lincoln Road". e "Abraham Lincoln Road" essere unito nella stessa strada. Penso anche che si basi su basi di dati nazionali contenenti corrispondenze di codice postale della città e così via.

Annuncio 2. Si crea un elenco a scelta multipla (ad es. dati di base) e le persone che aggiungono nuove voci scelgono tra le voci esistenti nei dati di base. Nella tabella dei fatti, memorizzi le chiavi per i nomi delle strade anziché i nomi delle strade stesse. Se rilevi un errore di ortografia, lo correggi solo nei tuoi dati di base e tutte le istanze vengono corrette con esso, attraverso la relazione chiave.

Nota che queste opzioni non si escludono a vicenda, puoi usare entrambi gli approcci contemporaneamente.

Le autorità su come sono costruiti gli indirizzi sono generalmente i servizi postali, quindi per prima cosa esaminerei gli elementi di dati utilizzati dai servizi postali per i principali mercati in cui operi.

Per informazioni molto specifiche e dettagliate sui formati di indirizzi postali internazionali consultare il sito Web dell'Unione postale universale: http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml

" xAl è la cosa più vicina a uno standard globale che è spuntato fuori. Sembra essere piuttosto esagerato, e non sono sicuro che molte persone vorrebbero implementarlo nel loro database ... "

Questo non è un argomento rilevante. L'implementazione di indirizzi non è un compito banale se il sistema deve essere "completo e coerente" (vale a dire in tutto il mondo). L'implementazione di tale standard richiede davvero molto tempo, ma per soddisfare il requisito specificato è comunque obbligatorio.

normalizza lo schema del tuo database e avrai la struttura perfetta per una coerenza corretta. ed è per questo che: http://weblogs.sqlteam.com/mladenp/archive/2008/09/17/Normalization-for-databases-is-like-Dependency-Injection-for-code.aspx

Ho chiesto qualcosa di abbastanza simile in precedenza: Dati / design dinamici delle informazioni di contatto modello: è in qualche modo possibile? .

La risposta breve: archiviare adderres o qualsiasi tipo di informazione di contatto in un database è complessa. Il link Extendible Address Language (xAL) sopra contiene alcune informazioni interessanti che sono le più vicine a una pratica / best practice standard che ho riscontrato ...

Negli Stati Uniti, suggerirei di scegliere un fornitore di cambio di indirizzo nazionale e modellare il DB dopo quello che restituiscono.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow