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

Qual è il formato corretto di un indirizzo / luogo geografico adatto a qualsiasi indirizzo sulla Terra? Al momento ho:

• nazione
• città
• strada
• numero
• dati di testo (per semplicità)
• cerniera lampo
• lat / lng

Ma credo di poterlo migliorare: potrebbe esserci uno stato / una regione di un paese o qualcosa del genere. O nessuna area / regione / stato, diciamo, a Singapore o Hong Kong.

Potrebbe non esserci strada, ma strada o viale o qualcos'altro. Un certo numero di un edificio potrebbe essere composto. Potrebbe esserci un piano. Un numero di stanza Eccetera....

Google ha sviluppato una libreria che consente di convalidare gli indirizzi postali per ogni paese del mondo, che è possibile utilizzare per progettare uno schema per archiviare questi dati.

Per iniziare, cerca i campi obbligatori più comuni tra gli indirizzi della tua base di clienti di destinazione e mentre identifichi altri paesi con requisiti diversi, puoi continuare a modificare il tuo schema.

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

[Address] nvarchar(max) not null

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

• La mancanza di convalida dei dati significa 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 database immettendo 2 GB di dati nel campo dell'indirizzo.

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

• Gli utenti possono inserire erroneamente un indirizzo incompleto o chiaramente sbagliato.

Per mitigare il primo problema, limita il campo a quello che ritieni sia un limite ragionevole. Personalmente, inizierei con 1000 caratteri, per poi 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 di ritorno all'utente per ridurre il rischio per l'utente di inserire un indirizzo incompleto o errato: la maggior parte degli utenti sa dove vivono e vedere una posizione diversa su una mappa darebbe loro immediatamente un indizio che dovrebbero controllare il loro input.

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 sia così, dovresti fidarti a priori dell'utente, anche se potrebbe sbagliarsi.

Ciò significa anche che è comunque necessario memorizzare l'input dell'utente originale, fianco a fianco con il 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 latitudine / longitudine ti daranno un punto sul globo, ma non è davvero utile per identificare le singole case. Prendi in considerazione solo un palazzone per esempio.

La soluzione migliore è controllare il servizio postale di ciascun paese per un formato ufficiale. Questo può essere ottimo per il tuo database back-end. Ma probabilmente dovrai semplificarlo per gli utenti finali in quanto conterrà molti più campi di quanti sono abituati.

Quello del Regno Unito, ad esempio, include cose come "località a doppia dipendenza", ma nessuno saprebbe cosa significasse se glielo chiedessi.

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

Ho sviluppato soluzioni software da utilizzare in molti paesi. Affrontiamo questo problema iniziando prima con l'entità più grande, vale a dire il paese quindi ha i campi fino al meno comune o il più piccolo. Funziona bene per tutti i paesi con cui abbiamo sperimentato finora. Abbiamo anche un sistema intelligente di prevenzione dei duplicati e la fusione per coloro che in qualche modo entrano nel sistema poiché gli utenti sono molto "creativi". Nella sezione admin abbiamo un ordine dei campi indirizzo per paese. vale a dire che il Giappone ha prima il codice postale / postale dove ultimo come Regno Unito / Stati Uniti.

In generale, utilizziamo:

• Nazione
• Post / CAP
• Stato / Provincia / Prefettura / County
• Città / Comune / Frazione
• Via / Strada / blocchi
• Nome / numero dell'edificio
• Informazioni specifiche / personalizzate

Una volta inserita e salvata, è possibile visualizzare una versione coniugata tralasciando i campi non necessari.

Come ho detto, questo funziona per tutti quei paesi in cui il software era dotato di software ed è il risultato dello sviluppo dal 1989.

Spero che questo aiuti in qualche modo o almeno fornisca un'altra intuizione.

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

È possibile separare il paese dal resto dell'indirizzo e memorizzarlo come codice paese ISO. Normalizzerebbe il paese e offrirebbe qualche utilità nel convalidare il resto dell'indirizzo.

Puoi anche separare il codice postale o CAP 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 in modo univoco qualsiasi indirizzo specificando solo il codice postale e il numero civico (ovvero il numero civico); questo potrebbe non essere vero in tutti i paesi.

Dedicare campi a stati / province o città inizia a diventare più problematico a causa delle variazioni nel modo in cui ciascun paese formula un indirizzo. Ho impostato tabelle di indirizzi con tali campi perché il pubblico iniziale è focalizzato sul Nord America, sapendo che un pubblico internazionale potrebbe creare un problema. Nella maggior parte dei casi, possono essere "con le scarpe", ma è un Compromesso imbarazzante e potenzialmente soggetto a guasti - sicuramente non universale.

Contrariamente alla risposta di Mitchdav, consiglierei di non utilizzare la biblioteca di Google. Ho cercato nel repository vari luoghi internazionali con schemi di indirizzamento non ortodossi nella speranza di trovare dati di test unitari, ma preoccupantemente ho trovato zero hit nell'intero repository.

Penso che la tua scommessa migliore sia trattare un indirizzo come testo a più righe in formato libero. 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 ricade sull'utente e nella maggior parte delle applicazioni l'utente porta conseguenze negative della compilazione di un indirizzo non valido.

Forse potresti usare un validatore per fornire un avviso , ma niente di più. Ma non rifiutare 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 che comunicherà che, se l'utente vive in un'area con uno strano formato di indirizzo, è sicuro ignorare l'avviso ...

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

https://what3words.com

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

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