Mejores prácticas para el almacenamiento de direcciones consistente y completo en una base de datos [cerrado]

StackOverflow https://stackoverflow.com/questions/126207

  •  02-07-2019
  •  | 
  •  

Pregunta

¿Existen mejores prácticas (o incluso estándares) para almacenar direcciones de manera coherente 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:

  • sólo necesitas asociar una dirección a una persona, un edificio o cualquier elemento (el caso más común).Entonces probablemente sea suficiente una tabla plana con columnas de texto (dirección1, dirección2, código postal, ciudad).Este no es el caso que me interesa.
  • desea ejecutar estadísticas sobre sus direcciones:¿Cuántos artículos hay en una calle, ciudad o...Entonces querrás 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 :Todavía no parece existir una respuesta perfecta a esta pregunta, pero:

  • xal, como sugerido por Hank, es lo más parecido a un estándar global que surgió.Sin embargo, parece una exageración y no estoy seguro de que mucha gente quiera implementarlo en su base de datos...
  • Para iniciar su propio diseño (para un país específico), enlace de dave hacia Unión Postal Universal (UPU) es un muy buen punto de partida.
  • En cuanto a Francia, existe una norma (no oficial, pero sí de facto) para las direcciones, que lleva el bonito nombre de AFNOR XP Z10-011 (sólo francés), y tiene que ser pagado.El UPU La descripción para Francia se basa en esta norma.
  • Encontré la norma equivalente para Suecia: SS 613401.
  • A nivel europeo se han realizado algunos esfuerzos que han dado como resultado la norma EN 14142-1.Se puede obtener a través de Miembros nacionales del CEN.
¿Fue útil?

Solución

Yo usaría un Address tabla, como usted ha sugerido, y la basaría en los datos rastreados por xal.

Otros consejos

Yo también he estado pensando en esto.Aquí están mis pensamientos vagos hasta ahora y me pregunto qué piensan otras personas.

xAL (y su hermano que incluye nombres personales, XNAL) es utilizado por los servicios de codificación geográfica de Google y Yahoo, lo que le otorga cierto peso.Pero dado que la misma dirección se puede describir en xAL de muchas maneras diferentes (algunas más específicas que otras), no veo cómo xAL en sí es un formato aceptable para el almacenamiento de datos.Sin embargo, se podrían usar algunos de sus nombres de campo, pero en realidad el único formato básico que se puede usar entre los 16 países a los que realiza envíos mi empresa 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 asignarlo a una única tabla de base de datos, solo permitiendo valores 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 debo modelar esto en un modelo de objetos que los programadores y cualquier código GUI puedan usar fácilmente.¿Tenemos una base? Address escriba con subclases para cada tipo de dirección, como AmericanAddress, CanadianAddress, GermanAddress, ¿Etcétera?Cada uno de estos tipos de direcciones sabría cómo formatearse 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 en 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 dirección individuales para cada país, podríamos adoptar el enfoque un poco menos orientado a objetos de tener una Address objeto que evita las propiedades .NET y utiliza un 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, eso Address objeto invocaría el método apropiado en su interior AddressStrategy objeto.

La razón para utilizar un SetField() El enfoque del método en lugar de propiedades con captadores y definidores es para que sea más fácil para el código configurar estos campos de forma genérica sin recurrir a declaraciones de reflexión o cambio.

Puedes imaginar el proceso siendo algo como esto:

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

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

¿Algo de esto tiene sentido?¿Me estoy desviando demasiado del camino de la programación orientada a objetos?Para mí, esto representa un compromiso bastante sensato entre ser tan abstracto que su implementación sea casi imposible (xAL) y estar estrictamente sesgado hacia Estados Unidos.

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

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

En el Reino Unido existe un producto llamado PAF de correo real

Esto le proporciona una clave única por dirección; sin embargo, hay obstáculos que superar.

Básicamente veo 2 opciones si quieres coherencia:

  1. Limpieza de datos
  2. Consultas de tablas 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 la misma calle.También creo que se basa en bases de datos nacionales que contienen coincidencias de códigos postales de ciudades, etc.

Anuncio 2.Usted crea una lista de opciones múltiples (es decir, datos básicos) y las personas que agregan nuevas entradas eligen entre las entradas existentes en sus datos básicos.En su tabla de hechos, almacena claves para los nombres de las calles en lugar de los nombres de las calles en sí.Si detectas un error ortográfico, simplemente lo corriges en tus datos básicos, y con él se corrigen todas las instancias, 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.

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

Consulte el sitio web de la Unión Postal Universal 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

"xAl es lo más parecido a un estándar global que surgió.Sin embargo, parece una exageración y no estoy seguro de que mucha gente quiera implementarlo en su base de datos..."

Este no es un argumento relevante.Implementar direcciones no es una tarea trivial si el sistema necesita ser "integral y consistente" (es decir,mundial).La implementación de una norma de este tipo lleva mucho tiempo, pero el cumplimiento de los requisitos especificados es, no obstante, obligatorio.

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

Pregunté algo bastante similar antes: Datos de información de contacto dinámicos/patrón de diseño:¿Es esto factible de alguna manera?.

La respuesta corta:Almacenar direcciones o cualquier tipo de información de contacto en una base de datos es complejo.El enlace de Lenguaje de direcciones extensible (xAL) anterior tiene información interesante que es lo más cercano a un estándar/mejor práctica con el que me he encontrado...

En los EE. UU., sugeriría elegir un proveedor de cambio de dirección nacional y modelar la base de datos según lo que devuelven.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top