¿Hay un layout común de la database de direcciones para todas las direcciones del mundo?

Soy un progtwigdor y, para ser sincero, no conozco las estructuras de las direcciones de las calles del mundo, ¿cómo está estructurado en mi país? ¿Cuál es el mejor y más común layout de database para almacenar direcciones de calles? Debe ser tan simple de usar, rápido de consultar y dynamic para almacenar todas las direcciones de las calles del mundo que está identificando con solo una identificación
Muchas gracias

Es posible representar direcciones de muchos países diferentes en un set estándar de campos. La idea básica de una ruta de acceso (vía) nombrada en la que se encuentran los edificios nombrados o numerados es bastante estándar, a exception de China a veces. Otros conceptos casi universales incluyen: nombrar el asentamiento (ciudad / pueblo / aldea), que se puede denominar genéricamente como localidad; nombrar la región y asignar un código postal alfanumérico. Tenga en count que los códigos postales, también conocidos como códigos postales, son puramente numéricos solo en algunos países. Necesitará muchos campos si realmente quiere ser genérico.

La UPU Universal Postal Union proporciona datos de direcciones para muchos países en un formatting estándar . Tenga en count que el formatting UPU contiene todas las direcciones (hasta la precisión de campo disponible) para todo un país, por lo tanto, es relacional. Si almacena direcciones de clientes, donde solo se almacenará una pequeña fracción de todas las direcciones posibles, es mejor usar una sola tabla (o formatting plano) que contenga todos los campos y una dirección por fila.

Un formatting razonable para almacenar direcciones sería el siguiente:

  • Dirección Líneas 1-4
  • Localidad
  • Región
  • Código postal (o código postal)
  • País

Las líneas de direcciones 1-4 pueden contener componentes tales como:

  • edificio
  • Sub-Edificio
  • Número de premisa (número de casa)
  • Gama de premisas
  • Vía pública
  • Sub-Ruta
  • Localidad de Doble Dependencia
  • Sublocalidad

Con frecuencia solo se usan 3 líneas de dirección, pero esto a menudo es insuficiente. Por supuesto, es posible requerir más líneas para representar todas las direcciones en el formatting oficial, pero las comas siempre se pueden usar como separadores de línea, lo que significa que la información aún se puede capturar.

Por lo general, el análisis de los datos se realizará por localidad, región, código postal y país, y estos elementos son bastante fáciles de entender para los usuarios al ingresar datos. Es por eso que estos elementos deben almacenarse como campos separados. Sin embargo, no obligue a los usuarios a proporcionar código postal o región, no pueden usarse localmente.

La localidad puede ser poco clara, particularmente la distinción entre localidad de map y localidad postal. La localidad postal es la que considera una autoridad postal, que a veces puede ser una gran ciudad cercana. Sin embargo, el código postal generalmente resolverá cualquier problema o discrepancia allí, para permitir la entrega correcta, incluso si no se utiliza la localidad postal oficial.

Eche un vistazo a Database Answers . Específicamente, esto cubre muchos casos:

AddressId Line1 Line2 Line3 City ZipOrPostcode StateProvinceCounty CountryId OtherAddressDetails 

enter image description here

Pregúntese cuál es el propósito principal de almacenar esta información. ¿Tiene la intención de enviar un correo a la persona en la dirección? Rastrear datos democharts, poblaciones? ¿Puede pedirle a las personas que llaman su dirección correcta como parte de una authentication / verificación básica? Todas las anteriores? ¿Ninguna de las anteriores?

Dependiendo de su necesidad real, determinará a) en realidad no importa, y puede optar por un enfoque de text libre, ob) campos estructurados / específicos para todos los países, oc) architecture específica de país.

Para las direcciones internacionales, es muy difícil encontrar una forma de formatear la información si se divide en campos. Como por ejemplo, una dirección italiana usa:

 <street address> <zip> <town> <region> <country> 

Como

 Via Eroi della Repubblica 89861 Tropea VV Italy 

Eso es bastante diferente del order para las direcciones de EE. UU., En la segunda línea.

Ver también las preguntas SO:

  • ¿Cuántos campos de dirección usarías para una database del Reino Unido?
  • ¿Rompe las direcciones en street / city / state / zip?
  • ¿Cómo manejas los sufijos callejeros duplicates?
  • ¿Mejores prácticas para almacenar direcciones postales en una database (RDBMS)?

También echa un vistazo a la label ' código postal '.


Editar : order inverso de región y ciudad – por UPU

A veces, lo más cerca que puede llegar a una calle es la ciudad.

Una vez tuve un proyecto para poner todas las escuelas secundarias de la India en Google Maps. Escribí un progtwig espectacular usando la API de Google y pensé que sería bastante fácil.

Luego obtuve la información del cliente. Algunas direcciones esqueueres eran cosas como "Al otro lado del mercado, al lado del barbero" o "Cerca de la parada de autobús antiguo".

Hizo mi tarea mucho más difícil ya que, lamentablemente, la API de Google no es compatible con ese formatting.

Quizás esto sea útil: https://gist.github.com/259744 Para un proyecto, recopilé una tabla de información sobre todos los países del mundo, incluidos códigos ISO, dominio de nivel superior, código de teléfono, señal de automobile, longitud y expresión regular de cremallera. Los nombres de los países y los comentarios lamentablemente solo en alemán …

A diferencia de otras respuestas aquí, creo que es posible tener una database de direcciones estructuradas.

Solo de la gorra, puedo pensar en la siguiente estructura:

  • País
  • Región (Estado / Provincia)
  • Localidad (Ciudad / Municipio)
  • Sublocalidad (Condado / otra subsplit de una localidad)
  • Calle

¿Pero cómo consultarlo lo suficientemente rápido?

Una forma en que siempre creo que se puede lograr es solicitar el código postal (o código postal) que varía de un país a otro, pero es sólido dentro del país.

De esta manera puede estructurar sus datos en torno a la información proporcionada por las oficinas postales de todo el mundo.

Depende de la forma libre que esté preparado para ir con los campos. Un campo de dirección de forma libre obviamente siempre servirá, pero será de poca ayuda para networkingucir la geografía.

El problema que tendrá es que hay demasiada variación en el nivel de jerarquía geográfica entre países. Diablos, algunos países ni siquiera tienen "direcciones de calles" en todas partes.

Te recomiendo que no trates de hacerlo demasiado inteligente.

Len Silverston de Universal Data Model fame recomienda una jerarquía separada de GEOGRAPHIC BOUNDARIES y dependiendo de la cantidad de forma libre que esté dispuesto a aceptar, ya sea STREET ADDRESS LINE simples de dirección de la STREET ADDRESS LINE o derivadas por país.

No, no hay un esquema de direccionamiento estándar. Por lo general, varía de un país a otro. Incluso la Unión Postal Universal dijo en Adressing the world, una dirección para todos que no la hay. La mejor solución para esto es usar los estándares de código de país de 2/3 letras conocidos como ISO 3166 y tratar todo lo demás según los estándares del país.

Sin embargo, si realmente está desesperado por utilizar herramientas de fácil acceso para su proyecto, puede probar Google Place API .

No absolutamente no. Si compara la forma en que funcionan las direcciones estadounidenses y japonesas , verá que no es posible.

ACTUALIZAR:

Pensándolo bien, se puede hacer cualquier cosa, pero hay una compensación.

Un enfoque es modelar el problema con las tablas address_attribute y address, con una relación 1: m entre ellas, cualquier cosa puede ser modelada. La tabla address_attribute tendría un pk, un nombre, un valor y un fk que apunta a su dirección parent's pk. Es casi como usar un Mapa con nombre, pares de valores.

La compensación es tener que hacer un JOIN cada vez que quiera una dirección. También debe interrogar los nombres de los attributes de dirección para descubrir con qué trata cada vez.

Otro enfoque sería realizar una investigación más exhaustiva sobre cómo se modelan las direcciones en todo el mundo. En un mundo orientado a objects, puede tener la class Dirección occidental (calle1 / calle2 / ciudad / estado / postal) y otras para Japón, China, tantas como sea necesario para delimitar el espacio de direcciones. Luego tendría una tabla de direcciones maestra y tablas secundarias para los otros types con una relación 1: 1 entre ellos.

¿Cómo lo hace Amazon o eBay? Ellos envían internacionalmente. ¿Tienen características de interfaz de usuario específicas de la configuration regional? Solo he usado la configuration regional de EE. UU.

Su layout debe depender fuertemente de su propósito. Algunas personas han publicado cómo estructurar los datos. Entonces, si simplemente desea enviar correos electrónicos a alguien, lo hará. Las cosas comienzan a complicarse si desea utilizar estos datos para la navigation. La navigation del automobile requerirá estructuras adicionales para contener información de tráfico (por ejemplo, paths de dirección única), mientras que la navigation a pie requerirá una gran cantidad de datos adicionales. Aquí hay un pequeño ejemplo: en mi ciudad, mi vecindario está cerca del parque. Al lado del parque se encuentra el antiguo aeródromo (de hecho, uno de los más antiguos de Europa) convertido en museo de aviación. Junto al museo de aviación hay un parque empresarial. El número de la calle para el museo es 39, mientras que los numbers del parque de negocios comienzan con 39A. Por lo tanto, puede parecer que 39 y 39A están cerca, pero se tarda aproximadamente una milla en caminar de uno a otro (y aún más si se va en automobile).
Este es solo un pequeño ejemplo tomado de mi ciudad, creo que probablemente puedas encontrar muchas excepciones (especialmente en partes rurales o más salvajes de cada país).