database - tool - Mejores prácticas para el almacenamiento de direcciones coherente e integral en una base de datos

database modeling online

Question

¿Existen mejores prácticas (o incluso estándares) para almacenar direcciones de una manera consistente y completa en una base de datos?

Para ser más específico, creo que en esta etapa hay dos casos para el almacenamiento de direcciones:

• solo necesita asociar una dirección a una persona, un edificio o cualquier elemento (el caso más común). Entonces, es probable que una mesa plana con columnas de texto (dirección1, dirección2, zip, ciudad) sea suficiente. Este no es el caso en el que estoy interesado.
• Desea ejecutar estadísticas sobre sus direcciones: cuántos elementos en una calle específica, o ciudad o ... Entonces desea evitar errores ortográficos de cualquier tipo y garantizar la coherencia. Mi pregunta es sobre las mejores prácticas en este caso específico: ¿cuáles son las mejores formas de modelar una base de datos de direcciones coherente?

Un diseño / solución específico para cada país sería un excelente comienzo.

RESPUESTA : No parece existir una respuesta perfecta para esta pregunta todavía, pero:

• xAL , como sugiere Hank , es lo más parecido a un estándar global que apareció. Sin embargo, parece ser bastante exagerado, y no estoy seguro de que muchas personas quieran implementarlo en su base de datos ...
• Para comenzar el propio diseño (para un país específico), el enlace de Dave al sitio de la Unión Postal Universal (UPU) es un muy buen punto de partida.
• En cuanto a Francia, existe una norma (no oficial, pero de facto estándar) para las direcciones, que lleva el bonito nombre de AFNOR XP Z10-011 (solo en francés), y debe pagarse. La descripción de la UPU para Francia se basa en esta norma.
• Encontré la norma equivalente para Suecia: SS 613401 .
• A nivel europeo, se han hecho algunos esfuerzos, lo que da como resultado la norma EN 14142-1. Se puede obtener a través de los miembros nacionales de CEN .

Answer 1

"xAl es lo más parecido a un estándar global que apareció. Sin embargo, parece ser bastante exagerado, y no estoy seguro de que muchas personas quieran implementarlo en su base de datos ..."

Este no es un argumento relevante. La implementación de direcciones no es una tarea trivial si el sistema debe ser "integral y consistente" (es decir, a nivel mundial). Implementar un estándar de este tipo lleva mucho tiempo, pero cumplir con el requisito especificado es obligatorio.

Answer 2

Básicamente veo 2 opciones si quieres coherencia:

1. Limpieza de datos
2. Búsquedas de tabla de datos básicos

Anuncio 1. Trabajo con SAS System, y SAS Institute ofrece una herramienta para la limpieza de datos: básicamente realiza algunas comprobaciones y validaciones de sus datos, y sugiere que "Abram Lincoln Road" y "Abraham Lincoln Road" se fusionen en el mismo calle. También creo que se basa en bases de datos nacionales que contienen coincidencias del código postal de la ciudad y así sucesivamente.

Anuncio 2. Usted crea una lista de opciones múltiples (es decir, datos básicos), y las personas que agregan nuevas entradas seleccionan entre las entradas existentes en sus datos básicos. En tu tabla de hechos, almacenas las claves de los nombres de las calles en lugar de los nombres de las calles. Si detecta un error ortográfico, simplemente corríjalo en sus datos básicos, y todas las instancias se corrigen con él, a través de la relación clave.

Tenga en cuenta que estas opciones no se excluyen entre sí, puede utilizar ambos enfoques al mismo tiempo.

Answer 3

En el Reino Unido hay un producto llamado PAF de Royal Mail

Esto le da una clave única por dirección, aunque hay aros para saltar.

Answer 4

En los Estados Unidos, sugiero elegir un proveedor de Cambio Nacional de Dirección y modelar el DB después de lo que devuelven.

Answer 5

He estado pensando sobre esto yo también. Aquí están mis pensamientos sueltos hasta ahora, y me pregunto qué piensan los demás.

xAL (y su hermana, que incluye nombres personales, XNAL) es utilizado tanto por los servicios de geocodificación de Google como de Yahoo, lo que le da algo de peso. Pero dado que la misma dirección se puede describir en xAL de muchas maneras diferentes, algunas más específicas que otras, entonces no veo cómo xAL en sí es un formato aceptable para el almacenamiento de datos. Sin embargo, algunos de sus nombres de campo podrían usarse, pero en realidad el único formato básico que se puede usar entre los 16 países a los que mi empresa envía es el siguiente:

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
}

Es bastante fácil mapear en una sola tabla de base de datos, permitiendo solo NULL en la mayoría de las columnas. Y parece que así es como Amazon y muchas organizaciones almacenan datos de direcciones. Entonces, la pregunta que queda es cómo debería modelar esto en un modelo de objetos que sea fácilmente utilizado por los programadores y por cualquier código GUI. ¿Tenemos un tipo de Address base con subclases para cada tipo de dirección, como AmericanAddress , CanadianAddress , GermanAddress , etc.? Cada uno de estos tipos de direcciones sabría cómo formatear ellos mismos y, opcionalmente, sabría un poco sobre la validación de los campos.

También podrían devolver algún tipo de metadatos sobre cada uno de los campos, como la siguiente estructura de datos de pseudocódigo:

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
}

De hecho, en lugar de tener objetos de direcciones individuales para cada país, podríamos tomar el enfoque ligeramente menos orientado a objetos de tener un objeto Address que evite las propiedades .NET y use una AddressStrategy para determinar las reglas de formato y validación:

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)
}

Al configurar un campo, ese objeto Address invocaría el método apropiado en su objeto interno AddressStrategy .

La razón para usar un enfoque de método SetField() lugar de propiedades con getters y setters es tal que es más fácil para el código establecer realmente estos campos de una manera genérica sin recurrir a sentencias de reflexión o cambio.

Puedes imaginarte que el proceso va más o menos así:

1. El código GUI llama a un método de fábrica o algo así para crear una dirección basada en un país. (El menú desplegable del país, entonces, es lo primero que el cliente selecciona, o tiene una buena conjetura preseleccionada para ellos según la información cultural o la dirección IP).
2. La GUI llama a la address.GetMetadata() o un método similar y recibe una lista de las estructuras de AddressFieldMetadata como se describió anteriormente. Puede usar estos metadatos para determinar qué campos mostrar (ignorando aquellos con el conjunto is-applicable a false ), qué etiquetar esos campos (usando el miembro del field-name del field-name ), visualizar esos campos en un orden particular y realizar una presentación superficial nivel de validación en esos datos (utilizando los miembros is-required , validation-regex y allowed-values ).
3. La GUI llama al método address.SetField() utilizando el field-number (que corresponde a la enumeración anterior) y sus valores dados. El objeto Address o su estrategia puede realizar una validación de dirección avanzada en esos campos, invocar limpiadores de dirección, etc.

Podría haber ligeras variaciones en lo anterior si queremos hacer que el objeto Address se comporte como un objeto inmutable una vez que se haya creado. (Lo cual probablemente intentaré hacer, ya que el objeto Address se parece más a una estructura de datos, y probablemente nunca tendrá un comportamiento verdadero asociado a sí mismo).

¿Algo de esto tiene sentido? ¿Me estoy alejando demasiado de la ruta OOP? Para mí, esto representa un compromiso bastante sensato entre ser tan abstracto que la implementación es casi imposible (xAL) versus estar estrictamente predispuesto por los EE. UU.

Actualización 2 años después: finalmente terminé con un sistema similar a este y escribí sobre él en mi difunto blog .

Siento que esta solución es el equilibrio correcto entre los datos heredados y el almacenamiento de datos relacionales, al menos para el mundo del comercio electrónico.

Answer 6

Las autoridades sobre cómo se construyen las direcciones son generalmente los servicios postales, así que para empezar examinaré los elementos de datos utilizados por los servicios postales para los principales mercados en los que opera.

Visite el sitio web de Universal Postal Union para obtener información muy específica y detallada sobre los formatos de direcciones postales internacionales: http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml

Answer 7

Pregunté algo bastante similar anteriormente: .

La respuesta corta: almacenar adderres o cualquier tipo de información de contacto en una base de datos es compleja. El enlace del Lenguaje Extensible de Dirección (xAL) de arriba tiene información interesante que es la más cercana a una práctica estándar / mejor que he encontrado ...

Answer 8

normalice su esquema de base de datos y tendrá la estructura perfecta para una coherencia correcta. y esta es la razón por la cual: http://weblogs.sqlteam.com/mladenp/archive/2008/09/17/Normalization-for-databases-is-like-Dependency-Injection-for-code.aspx

Answer 9

Utilizaría una tabla de Address , como sugirió, y la basaría en los datos rastreados por xAL .