¿Qué problemas se resuelven dividiendo las direcciones de las calles en columnas individuales?

Tenemos un equipo que diseña las tablas y las relaciones para los desarrolladores de software. En nuestra organización, son bastante estrictos sobre la aplicación de la normalización de 3NF, lo que para ser honesto, estoy de acuerdo con el tamaño de nuestra organización y cómo cambian las necesidades o los clientes con el tiempo. Solo hay un área que no tengo claro sobre las razones detrás de su decisión de diseño: direcciones.

Si bien esto se centra principalmente en las direcciones en los Estados Unidos, creo que esto podría aplicarse a cualquier país que lo haga. Cada parte de una dirección obtiene su propia columna en la tabla de direcciones. Por ejemplo, tome esta dirección estadounidense retorcida:

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

Se dividiría en la base de datos de esta manera:

• Callejero: 485
• Fracción callejera: 1/2
• Calle pre-direccional: N (Norte)
• Nombre de la calle: Smith
• Tipo de calle: ST (calle)
• Calle post-direccional: SW (suroeste)
• Ciudad: Chicago
• Estado: IL (Illinois)
• Código postal: 11111
• Código ZIP4: 2222
• País (se supone que es EE. UU.)
• Atención: Jane Doe
• PO Box: NULL
• Tipo de vivienda: APT (Apartamento)
• Número de vivienda: 300B

Y habría algunas otras columnas relacionadas con rutas rurales y rutas de contrato. Además, nuestra aplicación específica probablemente tendrá algunas direcciones internacionales. Los modeladores de datos dijeron que agregarían columnas específicas para direcciones internacionales, que serían los campos normales de línea 1, línea 2.

Al principio pensé que esto era una MANERA al agua. Investigar en línea repetidamente se refiere al uso de la línea de dirección 1, 2, 3 y posiblemente 4, luego dividir la ciudad, la región y el código postal. Tenemos un caso de uso para nuestra nueva aplicación donde esta granularidad es beneficiosa. Tenemos que validar que el usuario no está creando un negocio duplicado, y verificar la dirección es una de las validaciones. Nos podemos conseguir que funcione con línea de dirección 1 y 2, pero sería más difícil.

En cuanto a nuestra aplicación específica, necesitamos almacenar múltiples tipos de direcciones para empresas y personas (física, postal, envío, etc.). Es posible que necesitemos generar cartas de formulario imprimibles, pero ese requisito no se ha discutido hasta ahora.

Algunas otras cosas que las aplicaciones de nuestra organización deben admitir:

• Auditoría (con tablas de historial completas)
• Impresión de etiquetas postales
• Generando formularios impresos
• Informes (para gobiernos nacionales y regionales)

Si bien es posible que nuestra aplicación no esté haciendo todo lo que hacen todas las demás aplicaciones, la división de direcciones en múltiples componentes es un estándar empresarial donde trabajo. Independientemente de si nuestra aplicación se beneficiaría de ello, nos vemos obligados a hacerlo.

Pregunta de StackOverflow semi relacionada: ¿Dónde está un buen analizador de direcciones que se cerró, pero ilustra cuán difícil puede ser el análisis de direcciones?

Para que yo pueda entender mejor su decisión de diseño y vender a nuestro cliente la idea ...

¿Qué problemas se resuelven dividiendo la dirección de la calle en columnas individuales?

Puntos de bonificación para cualquiera que haya implementado un sistema como este, porque se encontraron con problemas.

Los problemas que se pueden resolver dividiendo incluyen

Validación Cualquier parte del nombre se puede comparar con una lista maestra. Los que no coinciden pueden ser rechazados. El código postal / código postal es un ejemplo obvio. Estos son emitidos y mantenidos por una autoridad independiente. Los únicos válidos son los emitidos por esa autoridad.

Clasificación y selección He visto casos en los que los cargos postales se reducen si el correo se entrega al servicio de entrega ya organizado hasta cierto punto. Tener las columnas correspondientes produce un valor comercial tangible.

Análisis Puede ser útil saber a dónde van sus pedidos, de una manera geográficamente jerárquica. Esto puede impulsar iniciativas de ventas, desarrollo de productos o pagos de comisiones, etc.

Duplicación de código Al hacer que todas las aplicaciones de una organización adopten el mismo modelo de datos (el del consumidor más complejo), se puede adoptar una única base de código en toda la empresa y mantenerla de manera consistente. La división del cabello duplicada sin fin puede evitarse, o al menos delegarse en las cabezas de las hélices. Las direcciones mantenidas por diferentes partes de la organización pueden actualizarse constantemente. El servicio al cliente y la satisfacción se pueden aumentar. El esfuerzo de desarrollo puede concentrarse en las partes únicas y de alto valor de un sistema.

Cuestiones legales Las leyes y los impuestos varían según la jurisdicción. Al capturar los valores de dirección detallados por separado, es más fácil hacer una referencia cruzada de datos transaccionales con los requisitos de cumplimiento.

Duplicación Es simple falsificar direcciones mantenidas como texto moviendo un elemento a la siguiente línea o volviendo a secuenciar algunas partes. Las direcciones completamente analizadas son más fáciles de comparar. Esto puede ser un simple problema de calidad de datos, o puede tener implicaciones de cumplimiento o de crédito si, por ejemplo, varias compañías fantasmas hacen grandes pedidos a la misma dirección de entrega, o si se usa una tarjeta de crédito para entregar en muchas ubicaciones dispersas en un período corto.

Las piezas de formateo que se guardan por separado se pueden combinar de cualquier forma que se adapte a las necesidades actuales. Si, por ejemplo, las etiquetas de impresión largas y delgadas se vuelven baratas, puede volver a formatearlas para usarlas.

Por supuesto, ninguno de estos puede aplicarse a ninguna aplicación específica. Los datos de este tipo son mucho más fáciles de analizar y validar en la fuente, cuando se recopilan, que en el análisis posterior. Por lo tanto, incluso si YAGNI puede ser mejor poner el esfuerzo adicional por adelantado por poco costo y un gran ahorro potencial futuro.

Finalmente, no descartaría el factor humano. El modelo de datos es producido por modeladores de datos. Es lo que hacen. Esa es su profesión. No te van a decir que lo descargues en un BLOB, ¿verdad?

Pasé 7 años desarrollando software para una compañía editorial y uno de los problemas más difíciles que abordamos fue analizar las direcciones de las calles en las listas de suscripción. Es útil dividir las direcciones en distintos campos, pero nunca se puede, NUNCA diseñar para cada posible aberración patológica de formatos y componentes de direcciones que el cerebro humano pueda idear.

Cada localidad puede tener sus peculiaridades, y eso es solo en los Estados Unidos. Lanza en otros países y las cosas se vuelven inmanejables muy rápidamente para cualquier enfoque que quiera analizar cada dirección. Solo dos ejemplos:

En España, el número de la calle siempre viene después del nombre de la calle y una coma, y ​​muchas direcciones contienen un número de piso ordinal, como 1 ° o 3ª, junto con las abreviaturas de "izquierda" ("Izda" que significa puerta izquierda después subes las escaleras), "derecha" ("Dcha") u otras posibilidades. Ahora multiplique esa peculiaridad por el número de diferentes países y áreas con diferentes costumbres históricas para direcciones ... (¿Japón? ¿Inglaterra rural? ¿Corea? ¿China?)

En Portland, OR, hay ejes NS y EW que dividen la ciudad en cuadrantes NW, NE, SW y SE (así como un "cuadrante" N, pero estoy divagando). Las calles NS se numeran gradualmente Este y Oeste a partir de este eje, y las direcciones en las calles EW están dictadas por el número de la calle NS que es el "bloque cien" del número (es decir, una casa en una calle EW entre las avenidas 11 y 12 tendría un número como 1123). Bastante estándar para direcciones de EE. UU.

De vez en cuando se topa con una dirección de Portland como 0205 SW Nebraska St . ¿Un cero a la izquierda? WTF? Ahí va mi integercolumna para el "número" de la casa.

Cuando se configuró la cuadrícula, el eje NS fue definido por el río Willamette. Todo al este del río era NE o SE, y al oeste del río NW o SW. A medida que la ciudad crecía hacia el sur, se toparon con el hecho inconveniente de que el río serpenteaba hacia el este, por lo que al proyectar el eje hacia el sur, tiene esta área problemática que está en el lado "oeste" del río, pero al este del eje. La solución fue agregar un cero inicial, en efecto un signo menos , con los números incrementándose hacia el Este desde la línea del eje.

Si yo fuera tú, dejaría de tener la esperanza de diseñar el sistema definitivo. No puedes cubrir todas las posibilidades, y se crearán otras nuevas a medida que la humanidad empuje a tierras previamente no desarrolladas.

Para direcciones de EE. UU., Eche un vistazo a lo que USPS ya ha hecho en la estandarización de direcciones y recuerde hacer la house_numbercolumna a varchar. Mientras estás en ello averiguar cómo se va a analizar 1634 ES Fort Ave carril .

Para el resto del mundo, probablemente intente abstraer campos adicionales para cubrir el 80-90% de lo que probablemente surja, y proporcionar un conjunto de campos no interpretados que puedan manejar todo lo demás cuando sea necesario. Es decir, si su analizador no puede manejar una dirección, guárdela sin analizar y marcada como tal. Si logra analizar una dirección, asegúrese de recordar el orden en que encontró los diversos campos para que pueda volver a ensamblarla en algo que se pueda entregar.

Iba a decir que el campo más importante será el código postal, pero incluso eso no es un hecho en muchos lugares.

Buena suerte. Esto puede ser un esfuerzo divertido y extremadamente frustrante, pero la clave de la cordura es saber cuándo dejar de intentarlo y simplemente almacenar la entrada sin analizar o analizar parcialmente con la entrada original como copia de seguridad.

Como todas las preguntas de diseño, hay un "depende" enormemente calificado. Depende de su historia de datos: cómo se recopilan los datos, cómo se usan, cómo se actualizan, etc. Todos mis comentarios deben tomarse como puntos de discusión, no como respuestas prácticas.

Parece que * podría beneficiarse más al usar un servicio de validación de direcciones que al intentar crear uno para usted. Si bien son costosos, muchos de estos servicios vienen con importantes descuentos por correo.

Por supuesto, hay un compromiso aquí, para ciertas historias de datos. Puede conservar las direcciones analizadas y crear una columna calculada (conjunto de columnas, probablemente) para la dirección combinada. Esta es una respuesta de implementación, con todas las advertencias normales implícitas.

He implementado el diseño de la dirección analizada. Es absolutamente necesario esto para la calidad de los datos y las necesidades de procesamiento de datos. Pero esa era una empresa que tenía direcciones físicas, direcciones postales, direcciones virtuales, etc.

El otro problema que puede surgir es que diferentes servicios postales requieren que se presente la misma información en diferentes formatos / pedidos / etc. Por lo tanto, tener las piezas modeladas permite presentar la misma información en una variedad de formatos y diseños.

Finalmente, no es necesario tener operaciones comerciales internacionales para admitir datos internacionales. Incluso las empresas con sede en los EE. UU. Deben admitir direcciones internacionales. Es un gran error de datos asumir que nunca lo tendrás. Los clientes se mudan, los proveedores cambian las oficinas centrales, la información de contacto del proveedor puede ser internacional incluso si tienen una oficina central en los Estados Unidos. Incluso si sus sistemas actuales cometieron ese error, no desea llevar este hacia adelante.

Recomiendo los escritos y blogs de Graham Rhind. Es el experto en el campo de datos sobre direcciones de todo tipo y las compensaciones asociadas con ellas.

_{* Todo lo que he dicho aquí es una generalización general. Hay tantas preguntas que tendría que ayudar a llegar a una solución de diseño que podría tomar algunas horas de conversación. Probablemente algunas fotos y algunos perfiles de datos también. Y luego muchas historias de datos realmente extravagantes sobre direcciones.}

Dejando a un lado el enorme desafío de analizar correctamente el galimatías impredecible que la gente suministra, el beneficio del análisis es que le brinda dimensiones para agrupar y clasificar. Código postal, por ejemplo. Sin embargo, no hay recompensa al analizar una dimensión específica hasta que necesite agrupar u ordenar en esa dimensión.

¿Qué es una dirección, de todos modos? Podría presentar un buen caso de que se trata de un identificador de ubicación, pero podría presentar un caso igualmente bueno de que son las instrucciones de entrega: "Calle abajo de la fábrica de cemento". En Australia, la gente piensa que los códigos postales son identificadores de ubicación, pero no lo son, son códigos de enrutamiento, instrucciones de entrega. 4702 es el Rockhampton Mail Center, un importante nodo de distribución que da servicio a una región que se extiende desde el mar hasta Emerald, una ciudad minera a 300 km tierra adentro.

Si desea identificar ubicaciones, Bing y Google pueden geocodificar directamente desde la cadena no analizada en coordenadas GPS, que pueden almacenarse en una tabla pequeña y sencilla junto con la cadena no analizada. Utilizan el único enfoque general con alguna posibilidad de obtener resultados consistentemente buenos: coincidencia parcial ponderada clasificada con una colosal base de datos de resultados validados.

Si desea instrucciones de entrega, le recomendamos que mantenga la cadena no analizada porque podría contener cualquier cosa .

Tenga en cuenta que en ambos casos he recomendado mantener la cadena sin analizar. Eso es porque

• es útil por derecho propio
• algún día descubrirás cómo analizarlo
• un par de días después de eso, descubrirá cómo analizarlo correctamente
• esto nunca termina

Podría decirse que una dirección es siempre instrucciones de entrega, que contiene al menos un identificador de ubicación. Una carta dirigida a "123 Main st, Emerald 4702" codifica tres ubicaciones: RMC en la parte norte de Rockhampton, Emerald y una dirección. La oficina de correos de Rockhampton simplemente lo enviará a RMC. RMC lo enviará a la oficina de correos de Emerald, y es de esperar que la oficina de correos de Emerald sepa dónde encontrar la calle 123 Main.

He implementado un sistema como este antes, aunque en los Países Bajos. La cuestión es que este tipo de información puede cambiar de más formas de lo que piensas. Las calles se renombran, las ciudades se fusionan, etc. Es bueno poder actualizar ese tipo de información sin analizar las direcciones como una sola cadena.

Separar el código postal / código postal, el nombre del edificio, el nombre de la carretera puede tener sentido. Pero luego, cuando comienzas a agregar "pueblo", "área", etc., se vuelve cuestionable, en comparación con solo la línea 1, la línea 2, etc. ¿Se debe poner el nombre de la "aldea" en el campo de la ciudad, o va en la línea debajo del nombre de la carretera, con la ciudad local en los campos de la ciudad? (Algunas personas se ofenden si llamas a donde viven en un pueblo en lugar de una ciudad, otras personas que viven en el mismo lugar se ofenden si lo llamas una ciudad en lugar de un pueblo).

Por lo tanto, intentar hacer algo elegante no es mejor que el sistema de verificación de direcciones que utiliza. Pero se pone aún peor. En el Reino Unido, TODAS las direcciones deben tener un código postal, pero aún así el código postal no se asigna hasta algún momento después de que se construye una casa ... ¡Entonces un sistema debe permitir que se rompan todas las reglas sobre direcciones!

Además de los problemas ya mencionados en otras respuestas, en algunos idiomas, en particular el germánico, los nombres de las calles tienden a ser compuestos. Por ejemplo, es común en muchos pueblos / ciudades alemanes tener una "Bahnhofstrasse", la calle que va a la estación de ferrocarril ("Bahnhof" significa estación de tren / tren, "Strasse" significa calle). Ciertamente, podría separar estos dos componentes, pero ahora, si desea volver a unirlos (mediante programación), se enfrenta a cuestiones de declinación.

O, en el "romance" o en los idiomas latinos, con frecuencia tiene nombres de calles de la forma "Rue de la Pais" o "Boulevard des Champs-Élysées". Ahora tiene una preposición ("de") y un artículo definido ("le" o "la") en la mezcla, y se pueden combinar. ¿Representan parte del tipo de calle o nombre de la calle? (Probablemente necesite almacenarlos en algún lugar, de lo contrario, volverá a caer en declive).

Una vez modelé algo como esto. Pero era una aplicación muy pequeña para la oficina de mantenimiento de propiedades residenciales de una universidad mediana (en los Estados Unidos). Hice las direcciones muy granulares por las siguientes razones:

• Había calles en el área con el mismo nombre pero con un "tipo" de calle diferente (por ejemplo, "Woods Avenue" vs "Woods Court").
• Los usuarios querían poder optimizar el trabajo de mantenimiento, por ejemplo, si hubiera dos o más solicitudes de servicio en el mismo bloque, éstas podrían ser manejadas al mismo tiempo.
• Los usuarios querían poder correlacionar problemas entre diferentes unidades (apartamentos) en el mismo edificio, por ejemplo, si más de un apartamento informaron temperaturas frías o agua insuficientemente caliente.

... y otras razones que ya no recuerdo. (Esto fue a fines de la década de 1980).

Y de nuevo, esto solo tenía sentido porque había un número razonablemente pequeño de direcciones (y reglas de formato de dirección) con las que lidiar. No creo que este enfoque se amplíe, incluso si se limita a las direcciones de EE. UU., Por razones que ya se dan en otras respuestas.