Quali problemi vengono risolti suddividendo gli indirizzi in singole colonne?

Abbiamo un team che progetta i tavoli e le relazioni per gli sviluppatori di software. Nella nostra organizzazione, sono piuttosto severi nel far rispettare la normalizzazione 3NF - che a dire il vero, sono d'accordo con la dimensione della nostra organizzazione e come le esigenze oi nostri clienti cambiano nel tempo. C'è solo un'area in cui non sono chiaro i motivi alla base della loro decisione di progettazione: gli indirizzi.

Mentre questo si concentra principalmente sugli indirizzi negli Stati Uniti, penso che questo potrebbe applicarsi a qualsiasi paese che lo fa. Ogni parte di un indirizzo ottiene la propria colonna nella tabella degli indirizzi. Ad esempio, prendi questo nodoso indirizzo americano:

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

Si dividerebbe nel database in questo modo:

• Numero civico: 485
• Frazione stradale: 1/2
• Via pre-direzionale: N (Nord)
• Nome della via: Smith
• Tipo di strada: ST (via)
• Via post-direzionale: SW (sud-ovest)
• Città: Chicago
• Stato: IL (Illinois)
• Codice postale: 11111
• Codice postale: 2222
• Paese (presunto essere USA)
• Attenzione: Jane Doe
• Casella postale: NULL
• Tipo di abitazione: APT (Appartamento)
• Numero dimora: 300B

E ci sarebbero alcune altre colonne relative alle rotte rurali e alle rotte contrattuali. Inoltre, la nostra specifica applicazione avrà probabilmente alcuni indirizzi internazionali al suo interno. I modellatori di dati hanno detto che avrebbero aggiunto colonne specifiche per gli indirizzi internazionali, che sarebbero i normali campi riga 1, riga 2.

All'inizio ho pensato che fosse MODO in mare. La ricerca online ripetutamente si riferisce all'utilizzo della riga dell'indirizzo 1, 2, 3 e possibilmente 4, quindi alla suddivisione di città, regione e codice postale. Abbiamo un caso d'uso per la nostra nuova applicazione in cui questa granularità è vantaggiosa. Dobbiamo confermare che l'utente non sta creando un'attività duplicata e che la verifica dell'indirizzo è una delle convalide. Siamo in grado di farlo funzionare con la linea di indirizzo 1 e 2, ma sarebbe più difficile.

Per quanto riguarda la nostra specifica applicazione, dobbiamo archiviare più tipi di indirizzi per aziende e persone (fisiche, postali, spedizioni, ecc.). Noi potremmo bisogno di generare lettere tipo stampabili, ma tale obbligo non è stato discusso finora.

Alcune altre cose che le applicazioni della nostra organizzazione devono supportare:

• Auditing (con tabelle cronologiche complete)
• Stampa di etichette postali
• Generazione di moduli stampati
• Rapporti (per i governi nazionali e regionali)

Mentre la nostra applicazione potrebbe non fare tutto ciò che fa ogni altra applicazione, dividere gli indirizzi in più componenti è uno standard aziendale in cui lavoro. Indipendentemente dal fatto che la nostra applicazione ne trarrebbe beneficio, siamo costretti a farlo.

Domanda StackOverflow semi-correlata: dov'è un buon parser di indirizzi che è stato chiuso, ma illustra quanto possano essere difficili gli indirizzi di analisi.

Per consentirmi di comprendere meglio la loro decisione di progettazione e di vendere l'idea del nostro cliente ...

Quali problemi vengono risolti suddividendo l'indirizzo in singole colonne?

Punti bonus per chiunque abbia implementato un sistema come questo, perché si sono imbattuti in problemi.

I problemi che possono essere risolti dividendo includono

Convalida Qualsiasi parte del nome può essere confrontata con un elenco principale. Quelli che non corrispondono possono essere respinti. Il codice postale / codice postale è un esempio evidente. Questi sono emessi e gestiti da un'autorità indipendente. Gli unici validi sono quelli emessi da tale autorità.

Ordinamento e selezione Ho visto casi in cui le spese postali sono ridotte se la posta viene consegnata al servizio di consegna già organizzato in una certa misura. Avere le colonne corrispondenti produce un valore commerciale tangibile.

Analisi Può essere utile sapere dove stanno andando i tuoi ordini, in modo geograficamente gerarchico. Ciò può determinare iniziative di vendita, sviluppo del prodotto o commissioni ecc.

Duplicazione del codice Avendo tutte le applicazioni in un'organizzazione che adottano lo stesso modello di dati (quello del consumatore più complesso), una base di codice singola può essere adottata a livello aziendale e mantenuta in modo coerente. La divisione dei capelli senza fine può essere evitata, o almeno delegata alle teste delle eliche. Gli indirizzi detenuti da diverse parti dell'organizzazione possono essere aggiornati in modo coerente. Il servizio clienti e la soddisfazione possono essere aumentati. Lo sforzo di sviluppo può concentrarsi sulle parti uniche e di alto valore di un sistema.

Questioni legali Le leggi e le imposte variano in base alla giurisdizione. Acquisendo separatamente i valori degli indirizzi dettagliati, è più semplice fare riferimento incrociato dei dati transazionali ai requisiti di conformità.

Duplicazione È semplice falsificare gli indirizzi conservati come testo spostando un elemento sulla riga successiva o ridimensionando alcune parti. Gli indirizzi completamente analizzati sono più facili da confrontare. Potrebbe trattarsi di un semplice problema di qualità dei dati o potrebbe avere implicazioni sulla conformità o sul credito se, per esempio, più società di shell effettuano ordini di grandi dimensioni allo stesso indirizzo di consegna o una carta di credito viene utilizzata per consegnare in molte località disperse in un breve periodo.

Le parti di formattazione detenute separatamente possono essere combinate in qualsiasi modo si adatti alle esigenze attuali. Se, per esempio, le etichette lunghe e sottili diventano economiche, puoi riformattarle per usarle.

Naturalmente nessuno di questi può applicarsi a nessuna applicazione specifica. I dati di questo tipo sono molto più facili da analizzare e convalidare alla fonte, quando raccolti, di quanto non lo saranno mai in post analisi. Quindi, anche se YAGNI potrebbe essere meglio mettere in primo piano lo sforzo extra per un costo ridotto e un potenziale grande risparmio futuro.

Infine, non respingerei il fattore umano. Il modello di dati è prodotto da modellatori di dati. È quello che fanno. Questa è la loro professione. Non ti diranno di scaricarlo in un BLOB, vero?

Ho trascorso 7 anni a sviluppare software per una casa editrice e uno dei problemi più difficili che abbiamo mai affrontato era l'analisi degli indirizzi nelle liste di abbonamenti. È utile suddividere gli indirizzi in campi distinti, ma non puoi mai, MAI progettare per ogni possibile aberrazione patologica di formati e componenti di indirizzi che il cervello umano può escogitare.

Ogni località può avere le sue stranezze, e questo è solo negli Stati Uniti. Gettare in altri paesi e le cose diventano ingestibili molto rapidamente per qualsiasi approccio che voglia analizzare ogni indirizzo. Solo due esempi:

In Spagna, il numero civico viene sempre dopo il nome della via e una virgola, e molti indirizzi contengono un numero ordinale, come 1 ° o 3ª, insieme alle abbreviazioni per "sinistra" ("Izda" che significa porta a sinistra dopo ti alzi le scale), "giusto" ("Dcha") o altre possibilità. Ora moltiplica quella stranezza per il numero di diversi paesi e aree con differenti costumi storici per gli indirizzi ... (Giappone? Inghilterra rurale? Corea? Cina?)

A Portland, OR, ci sono assi NS ed EW che dividono la città in quadranti NW, NE, SW e SE (così come un "quadrante" N, ma sto divagando). Le strade NS sono numerate in modo incrementale verso est e ovest da questo asse e gli indirizzi sulle strade EW sono dettati dal numero civico NS che è il "cento blocco" del numero (vale a dire che una casa su una strada EW tra l'undicesima e la dodicesima strada avrebbe un numero come 1123). Roba abbastanza standard per indirizzi statunitensi.

Ogni tanto si esegue in un indirizzo di Portland come 0205 SW Nebraska St . Uno zero iniziale? WTF? Ecco la mia integercolonna per il "numero" di casa.

Quando è stata istituita la griglia, l'asse NS è stato definito dal fiume Willamette. Tutto ad est del fiume era NE o SE, e ad ovest del fiume NW o SW. Man mano che la città cresceva a sud, si imbatterono nel fatto scomodo che il fiume si snodava verso est, quindi proiettando l'asse sud si ha questa area problematica che si trova sul lato "ovest" del fiume ma ad est dell'asse. La soluzione era quella di aggiungere uno zero iniziale, in effetti un segno meno , con i numeri che aumentavano verso est dalla linea dell'asse.

Se fossi in te, perderei la speranza di progettare il sistema definitivo. Non puoi coprire tutte le possibilità e ne verranno create di nuove mentre l'umanità spinge in terre precedentemente non sviluppate.

Per gli indirizzi statunitensi, dai un'occhiata a ciò che USPS ha già fatto nella standardizzazione degli indirizzi e ricorda di rendere la house_numbercolonna a varchar. Mentre si è in esso capire come si sta andando a analizzare 1.634 EN Fort Vicolo Ave .

Per il resto del mondo, probabilmente proverei a sottrarre campi aggiuntivi per coprire l'80-90% di ciò che è probabile che arrivi, e fornire una serie di campi non interpretati in grado di gestire tutto il resto quando necessario. Cioè se il tuo parser non riesce a gestire un indirizzo, salvalo non analizzato e contrassegnato come tale. Se riesci ad analizzare un indirizzo, assicurati di ricordare l'ordine in cui hai trovato i vari campi in modo da poterlo riassemblare in qualcosa di consegnabile.

Stavo per dire che il campo più importante sarà il codice postale, ma anche questo non è un dato di fatto in molti luoghi.

In bocca al lupo. Questo può essere uno sforzo divertente ed estremamente frustrante, ma la chiave per la sanità mentale è sapere quando smettere di provare e archiviare l'input non analizzato o parzialmente analizzato con l'input originale come backup.

Come tutte le domande di progettazione, esiste un "dipende" altamente qualificato. Dipende dalla tua storia dei dati: come vengono raccolti i dati, come vengono utilizzati, come vengono aggiornati, ecc. Tutti i miei commenti dovrebbero essere presi come punti di discussione, non come risposte pratiche.

Sembra che * potresti trarre maggiori benefici dall'utilizzo di un servizio di convalida dell'indirizzo piuttosto che dal tentativo di crearne uno tu stesso. Sebbene siano costosi, molti di questi servizi comportano notevoli sconti postali.

Naturalmente, c'è un compromesso qui, per alcune storie di dati. È possibile mantenere persistenti i pezzi dell'indirizzo analizzati e creare una colonna calcolata (insieme di colonne, probabilmente) per l'indirizzo combinato. Questa è una risposta di implementazione, con tutte le normali avvertenze implicite.

Ho implementato il design dell'indirizzo analizzato. Ne avevamo assolutamente bisogno per la qualità e le esigenze di elaborazione dei dati. Ma quella era un'azienda che aveva indirizzi fisici, indirizzi postali, indirizzi virtuali, ecc.

L'altro problema che può sorgere è che servizi postali diversi richiedono che le stesse informazioni siano presentate in formati / ordini / ecc. Diversi. Pertanto, la modellazione delle parti supporta la presentazione delle stesse informazioni in una varietà di formati e layout.

Infine, non è necessario disporre di operazioni commerciali internazionali per supportare i dati internazionali. Anche le aziende con sede negli Stati Uniti devono supportare indirizzi internazionali. È un enorme errore di dati supporre che non lo avrai mai. I clienti si spostano, i fornitori cambiano sede, le informazioni di contatto del fornitore possono essere internazionali anche se hanno una sede USA. Anche se i tuoi attuali sistemi hanno commesso questo errore, non vuoi portarlo avanti.

Consiglio vivamente gli scritti e i blog di Graham Rhind. È l'esperto nel campo dei dati sugli indirizzi di tutti i tipi e sui compromessi ad essi associati.

_{* Tutto quello che ho detto qui è una generalizzazione grossolana. Ci sono così tante domande che dovrei aiutare a trovare una soluzione di progettazione che potrebbero richiedere alcune ore di chat. Probabilmente anche alcune immagini e alcuni dati di profilazione. E poi molte storie di dati davvero bizzarre sugli indirizzi.}

Tralasciando completamente l'enorme sfida di analizzare correttamente l'imprevedibile incomprensibilità che le persone forniscono, il vantaggio dell'analisi è che ti dà dimensioni per il raggruppamento e l'ordinamento. CAP, ad esempio. Tuttavia, non vi è alcun profitto dall'analisi di una dimensione specifica fino a quando non è necessario raggruppare o ordinare su quella dimensione.

Che cosa è un indirizzo, in ogni caso? Potresti sostenere che si tratta di un identificatore di posizione, ma potresti anche affermare che sono le istruzioni di consegna: "In fondo alla strada dalla fabbrica di cemento". In Australia, le persone pensano che i codici postali siano identificatori di posizione, ma non lo sono, sono codici di instradamento - istruzioni di consegna. 4702 è Rockhampton Mail Centre, un importante nodo di distribuzione che serve una regione che si estende dal mare a Emerald, una città mineraria di 300 km nell'entroterra.

Se si desidera identificare posizioni, Bing e Google possono geocodificare direttamente dalla stringa non analizzata in coordinate GPS, che possono essere memorizzate in una piccola tabella semplice insieme alla stringa non analizzata. Usano l'unico approccio generale con qualsiasi possibilità di risultati costantemente buoni: corrispondenza parziale ponderata classificata con un colossale database di risultati convalidati.

Se desideri istruzioni sulla consegna, ti consigliamo comunque di conservare la stringa non analizzata perché potrebbe contenere qualsiasi cosa .

Si noti che in entrambi i casi ho raccomandato di mantenere la stringa non analizzata. È perché

• è utile a sé stante
• un giorno scoprirai come analizzarlo
• un paio di giorni dopo, scoprirai come analizzarlo correttamente
• questo non finisce mai

Probabilmente un indirizzo è sempre istruzioni di consegna, contenente almeno un identificatore di posizione. Una lettera indirizzata a "123 Main st, Emerald 4702" codifica tre posizioni: RMC nella parte nord di Rockhampton, Emerald e un indirizzo. L'ufficio postale di Rockhampton lo invierà semplicemente a RMC. RMC lo invierà all'ufficio postale di Smeraldo, e si spera che l'ufficio postale di Smeraldo sappia dove trovare la strada principale 123.

Ho implementato un sistema come questo prima, anche se nei Paesi Bassi. Il fatto è che questo tipo di informazioni può cambiare in più modi di quanto si pensi. Le strade vengono rinominate, le città vengono unite e così via. È bello poter aggiornare quel tipo di informazioni senza analizzare gli indirizzi come una singola stringa.

Separare codice postale / codice postale, nome dell'edificio, nome della strada può avere senso. Ma poi quando inizi ad aggiungere "città", "area" ecc. Diventa discutibile, rispetto solo alla linea 1, alla linea 2 ecc. Il problema è che nemmeno io e mia moglie possiamo concordare sul nome della città in cui viviamo! Il nome del “villaggio” deve essere inserito nel campo della città, o va nella riga sotto il nome della strada, con la città locale inserita nei campi della città? (Alcune persone si offendono se chiami dove vivono un villaggio anziché una città, altre persone che vivono nella stessa posizione si offendono se lo chiami una città invece di un villaggio!)

Pertanto, provare a fare qualsiasi cosa di fantasia non è migliore del sistema di verifica dell'indirizzo che si utilizza. Ma va ancora peggio. Nel Regno Unito TUTTI gli indirizzi dovrebbero avere un codice postale, ma tuttavia il codice postale non viene assegnato fino a quando non viene costruita una casa …… Quindi un sistema deve consentire la violazione di ogni regola relativa all'indirizzo!

Oltre ai problemi già menzionati in altre risposte, in alcune lingue - in particolare germanico - i nomi delle strade tendono ad essere composti. Ad esempio, è comune in molte città tedesche avere una "Bahnhofstrasse", la strada che porta alla stazione ferroviaria ("Bahnhof" che significa stazione ferroviaria / treno, "Strasse" che significa strada). Certamente potresti separare questi due componenti, ma ora se vuoi rimetterli insieme (a livello di codice) ti stai mettendo in discussione la declinazione.

Oppure, nelle lingue "romanticismo" o in latino, hai spesso nomi di strade nella forma "Rue de la Pais" o "Boulevard des Champs-Élysées". Ora hai una preposizione ("de") e un articolo definito ("le" o "la") nel mix - e possono essere combinati. Rappresentano parte del tipo di strada o del nome della via? (Probabilmente è necessario memorizzarli da qualche parte, altrimenti si sta nuovamente in declino.)

Una volta ho modellato qualcosa del genere. Ma era un'applicazione molto piccola, per l'ufficio di manutenzione delle proprietà residenziali di un'università di medie dimensioni (negli Stati Uniti). Ho reso gli indirizzi molto granulari per i seguenti motivi:

• Nella zona c'erano strade con lo stesso nome ma un "tipo" di strada diverso (ad esempio "Woods Avenue" vs "Woods Court").
• Gli utenti volevano essere in grado di ottimizzare i lavori di manutenzione, ad esempio se nello stesso blocco c'erano due o più richieste di assistenza che potevano essere gestite contemporaneamente.
• Gli utenti volevano essere in grado di correlare i problemi tra diverse unità (appartamenti) nello stesso edificio, ad esempio se più di un appartamento ha riportato temperature fredde o acqua insufficientemente calda.

... e altri motivi che non ricordo più. (Era alla fine degli anni '80).

E ancora, questo aveva senso solo perché c'era un numero ragionevolmente piccolo di indirizzi (e regole di formattazione degli indirizzi) da trattare. Non credo che questo approccio si ridimensionerebbe, anche se limitato agli indirizzi statunitensi, per ragioni già fornite in altre risposte.