Qual è un modo universale per memorizzare un indirizzo / posizione geografica in un database? [chiuso]

Google ha sviluppato una libreria che aiuta a convalidare gli indirizzi postali per ogni paese del mondo, che puoi utilizzare per progettare uno schema per memorizzare questi dati.

Cerca i campi obbligatori più comuni tra gli indirizzi della tua base clienti mirata per iniziare e, quando individui altri paesi con requisiti diversi, puoi continuare a modificare lo schema.

Il modo universale per memorizzare un indirizzo / posizione geografica in un database è questo:

[Address] nvarchar(max) not null

Ciò richiede la minor quantità di codice di programmazione (e quindi riduce i costi di manutenzione) ed è completamente compatibile con qualsiasi indirizzo. Ha, tuttavia, tre grandi problemi:

• La mancanza di convalida dei dati indica che il campo può essere utilizzato per scopi diversi dalla memorizzazione dell'indirizzo. Uno degli scopi è un attacco DOS destinato a riempire lo spazio del tuo database inserendo 2 GB di dati nel campo dell'indirizzo.

• I dati memorizzati in questo modo rendono impossibile l'elaborazione per scopi di business intelligence e data mining. Ad esempio, quanti utenti provengono dall'India? Non c'è un modo semplice per dirlo, dal momento che quegli indirizzi non saranno normalizzati.

• Gli utenti potrebbero erroneamente inserire un indirizzo incompleto o chiaramente errato.

Per mitigare il primo problema, limita il campo a ciò che ritieni sia un limite ragionevole. Personalmente, vorrei iniziare con 1000 caratteri e quindi ridurlo in base alla lunghezza degli indirizzi inseriti dai primi utenti una volta ottenuto un set di dati abbastanza grande.

Per mitigare gli altri due problemi, puoi utilizzare un'API di terze parti che analizza gli indirizzi e ti presenta i dati contenenti il paese, la città, il codice postale, ecc. Se possibile, l'API dovrebbe essere in grado di visualizzare l'indirizzo su una mappa per l'utente per ridurre il rischio per l'utente di inserire un indirizzo incompleto o errato: la maggior parte degli utenti sa dove vive e vedere una posizione diversa su una mappa darebbe loro immediatamente l'idea che dovrebbero controllare la loro ingresso.

Nota che qualunque API tu usi, non sarà perfetta. Troverà la maggior parte degli indirizzi, ma non tutti. Ciò significa che se l'API dice che l'indirizzo non esiste, ma l'utente insiste che lo fa, dovresti a priori fidarti dell'utente, anche se potrebbe essere sbagliato.

Questo significa anche che dovresti comunque memorizzare l'input dell'utente originale, affiancato al risultato dell'API. Ciò significa che lo schema diventa:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

Non ce n'è uno.

Ogni paese ha diversi formati di indirizzo. Se sei fortunato, e hanno un formato a tutti!

Ovviamente la latitudine / longitudine ti darà un punto sul globo, ma non è davvero utile per identificare le singole case. Ad esempio, prendi in considerazione un blocco tower.

La soluzione migliore è controllare i servizi postali di ciascun paese per un formato ufficiale. Questo può essere ottimo per il tuo database di back-end. Ma probabilmente dovrai semplificarlo per gli utenti finali poiché conterrà molti più campi di quelli a cui la maggior parte della gente è abituata.

Il Regno Unito, ad esempio, include cose come "doppia località dipendente", ma nessuno saprebbe cosa significava se glielo chiedeste.

L'unico formato universale è quello di avere un singolo campo di testo che può avere più righe di testo. Ciò consentirà qualsiasi indirizzo possibile sulla terra.

Ho sviluppato soluzioni software da utilizzare in molti paesi. Affrontiamo questo problema iniziando dall'entità più grande in primo luogo, cioè il paese quindi ha campi meno comuni o più piccoli. Funziona bene per tutti i paesi che abbiamo sperimentato finora. Abbiamo anche un sistema intelligente di prevenzione dei duplicati e la fusione per coloro che sono in qualche modo entrati nel sistema poiché gli utenti sono molto "creativi". Nella sezione admin abbiamo un ordine del campo indirizzo per impostazione del paese. Ad esempio, il Giappone ha il codice postale / codice postale per la prima volta nel Regno Unito / Stati Uniti.

In generale, usiamo:

• Paese
• Post / CAP
• Stato / Provincia / Prefettura / Contea
• Città / Comune / Frazione
• Via / Strada / blocchi
• Nome edificio / numero
• Informazioni specifiche / personalizzate

Una volta inseriti e salvati, è possibile visualizzare una versione coniugata lasciando i campi non necessari.

Come ho detto, questo funziona per tutti quei Paesi in cui è presente software con software ed è il risultato dello sviluppo dal 1989.

Spero che questo aiuti in qualche modo o almeno fornisca un altro approfondimento.

Come già detto, il più universale (ma poco pratico da convalidare e forse meno utile) è un singolo grande campo unicode.

Potresti separare il Paese dal resto dell'indirizzo e memorizzarlo come codice paese ISO. Normalizzerebbe il paese e offrirà qualche utilità nella convalida del resto dell'indirizzo.

Potresti anche separare il codice postale, ovvero il codice postale, dal resto dell'indirizzo. Ciò avrebbe anche qualche utilità nel convalidare il resto dell'indirizzo e potrebbe essere utile (anche se impreciso) nella geolocalizzazione. Ad esempio: in Canada è possibile identificare univocamente qualsiasi indirizzo specificando solo il codice postale e il numero civico (ovvero il numero civico); questo potrebbe non essere vero in tutti i paesi.

Dedicando i campi a stati / province o città inizia a diventare più problematico a causa delle variazioni nel modo in cui ogni paese formula un indirizzo. Ho impostato le tabelle di indirizzi con tali campi perché il pubblico iniziale si concentra sul Nord America, sapendo che un pubblico internazionale potrebbe rappresentare un problema di adattamento. Nella maggior parte dei casi, possono essere "calpestati", ma è un compromesso scomodo e potenzialmente incline al fallimento - decisamente non universale.

Contrariamente alla risposta di Mitchdav, sconsiglio di utilizzare la libreria di Google. Ho cercato il repository per vari posti internazionali con schemi di indirizzamento non ortodossi sperando di trovare dati di test unitari, ma preoccupato ho trovato zero colpi nell'intero repository.

Penso che la cosa migliore da fare sia trattare un indirizzo come testo multilinea a forma libera. Fa schifo che forse non è possibile convalidare tutti gli indirizzi, ma alcuni formati di indirizzamento sono davvero strani e forse imprevisti e alla fine la responsabilità di compilare l'indirizzo corretto è sull'utente e nella maggior parte delle applicazioni l'utente subisce conseguenze negative di compilazione indirizzo non valido.

Potresti, forse, usare un validatore per fornire un avviso , ma niente di più. Ma non rifiutare gli indirizzi che non convalidano, perché altrimenti potresti perdere alcuni clienti. Il che porta alla domanda su come comunicare l'avviso all'utente in modo tale da comunicare che, se l'utente vive in un'area con un formato di indirizzo strano, è possibile ignorare l'avviso ...

Come dici qualsiasi indirizzo sulla terra c'è solo lat long o ...

link

Che 3 parole, è un algoritmo (quindi non un database così può essere incorporato in qualcosa) che può definire una patch 3x3 metri ovunque sulla Terra.

Tonga e alcuni altri stati l'hanno adottato come sistema di codice postale, mentre non lo sostituirà come un overlay piuttosto interessante, e molto ben costruito e pensato.