¿Existe un diseño de base de datos de direcciones comunes para todas las direcciones del mundo?

Echa un vistazo a Respuestas de la base de datos. Específicamente, esto cubre muchos casos:

(Todo tipo de datos de caracteres de longitud variable)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Pregúntese cuál es el principal propósito de almacenar estos datos? ¿Tiene la intención de enviar correo a la persona en la dirección? ¿Rastrear demografía, poblaciones? ¿Ser capaz de pedir a las personas que llaman su dirección correcta como parte de una autenticación/verificación básica? Todo lo anterior? ¿Ninguna de las anteriores?

Dependiendo de su necesidad real, determinará a) realmente no importa, y puede optar por un enfoque de texto libre, o b) campos estructurados / específicos para todos países, o c) arquitectura específica de cada país.

A veces lo más cercano a una dirección es la ciudad.

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

Luego obtuve los datos del cliente. Algunas direcciones de la escuela eran cosas como "Frente al mercado, al lado del barbero" o "Cerca de la vieja parada de autobuses".

Hizo mi tarea mucho más difícil ya que, desafortunadamente, la API de Google no admite ese formato.

Para las direcciones internacionales, es muy difícil encontrar una manera de formatear la información si se desglosa en campos. Por ejemplo, una dirección italiana utiliza:

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

Como

Via Eroi della Repubblica
89861 Tropea VV
Italy

Eso es bastante diferente de la orden 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 base de datos del Reino Unido?
• ¿Divides las direcciones en calle / ciudad / estado / zip?
• ¿Cómo lidias con sufijos de calle duplicados?
• Mejores prácticas para almacenar direcciones postales en una base de datos (RDBMS)?

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

Editar : Orden inverso de región y ciudad - por UPU

Tal vez 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 los códigos ISO, el dominio de nivel superior, el código telefónico, el letrero del automóvil, la longitud y la expresión regular del código postal. Nombres de países y comentarios desafortunadamente solo en alemán...

A diferencia de otras respuestas aquí, creo que es posible tener una base de datos de direcciones estructurada.

Justo fuera del sombrero, puedo pensar en la siguiente estructura:

• País
• Región (Estado / Provincia)
• Localidad (Ciudad / Municipio)
• Sub-Localidad (Condado / otra subdivisión de una localidad)
• Street

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

Una forma en que siempre pienso que se puede lograr es pedir 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 relativamente poca ayuda para reducir la geografía.

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

Te recomiendo que no intentes hacerlo demasiado inteligente.

Len Silverston de Universal Data Model fame recomienda una jerarquía separada de GEOGRAPHIC BOUNDARIES y dependiendo de la cantidad de formación libre que esté dispuesto a aceptar ya sea simples STREET ADDRESS LINEs o derivados 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 Dirigiéndose al mundo, una dirección para todos que no hay ninguna. 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ás desesperado por usar herramientas de fácil acceso para tu proyecto, puedes probar Google Coloque API .

No, absolutamente no. Si comparas la forma en que funcionan las direcciones US y japonesas, verás que no es posible.

ACTUALIZACIÓN:

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

Un enfoque es modelar el problema con tablas address y address_attribute, 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 hacia el pk del padre de su dirección. Es casi como usar un mapa con nombre, pares de valores.

La compensación es tener que hacer una UNIÓN cada vez que desee una dirección. También tienes que interrogar los nombres de los address_attributes para averiguar con qué estás lidiando cada vez.

Otro enfoque sería hacer una investigación más exhaustiva sobre cómo se modelan las direcciones en todo el mundo. En un mundo orientado a objetos, es posible que tenga la clase de dirección occidental (street1/street2/city/state/zip) y otras para Japón, China, tantos como sea necesario para el espacio de direcciones. Luego tendría una tabla de direcciones maestra y tablas secundarias a los otros tipos con una relación 1: 1 entre ellos.

¿Cómo lo hace Amazon o eBay? Hacen envíos internacionales. ¿Tienen características de interfaz de usuario específicas de la configuración regional? Sólo he usado el local de Estados Unidos.

Su diseño debe depender en gran medida de su propósito. Algunas personas han publicado cómo estructurar los datos. Así que si simplemente desea enviar s-mail a alguien, lo hará. Las cosas comienzan a complicarse si desea utilizar estos datos para la navegación. La navegación de automóviles requerirá estructuras adicionales para contener información de tráfico (por ejemplo, carreteras de un solo sentido), mientras que la navegación 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 es antiguo aeródromo (de hecho, uno de los más antiguos de Europa) se convirtió en museo de la aviación. Junto al museo de la aviación hay un parque empresarial. El número de calle del museo es 39, mientras que los números del parque empresarial comienzan con 39A. Por lo que puede parecer que 39 y 39A están cerca, pero se necesita aproximadamente una milla para caminar de uno a otro (y aún más si se va en coche) .
Este es solo un pequeño ejemplo tomado de mi ciudad, creo que probablemente se pueden encontrar muchas excepciones (especialmente en las partes rurales o más salvajes de cada país).