¿Cuál es una forma universal de almacenar una dirección / ubicación geográfica en una base de datos? [cerrado]

¿Cuál es el formato correcto de una dirección / ubicación geográfica que sea adecuada para cualquier dirección en la Tierra? Por el momento tengo:

• país
• ciudad
• calle
• número
• datos de texto (por simplicidad)
• cremallera
• lat / lng

Pero creo que puedo mejorarlo: puede haber un estado / región de un país o algo así como un área. O no hay área / región / estado, por ejemplo, en Singapur o Hong Kong.

Puede que no haya calle, sino camino o bulevar o algo más. Varios edificios pueden estar compuestos. Puede haber un piso. Un número de habitación. Etc ...

Google ha desarrollado una biblioteca que ayuda a validar las direcciones postales de todos los países del mundo, que puede utilizar para diseñar un esquema para almacenar estos datos.

Para comenzar, busque los campos obligatorios más comunes en las direcciones de su base de clientes objetivo y, a medida que identifique más países con diferentes requisitos, puede continuar ajustando su esquema.

La forma universal de almacenar una dirección / ubicación geográfica en una base de datos es esta:

[Address] nvarchar(max) not null

Esto requiere la menor cantidad de código de programación (y así reduce los costos de mantenimiento) y es totalmente compatible con cualquier dirección. Sin embargo, tiene tres grandes problemas:

• La falta de validación de datos significa que el campo se puede utilizar para fines distintos al almacenamiento de la dirección. Uno de los propósitos es un ataque de DOS destinado a llenar el espacio de su base de datos al ingresar 2 GB de datos en el campo de dirección.

• Los datos almacenados de esta manera hacen que sea imposible procesarlos para fines de inteligencia empresarial y minería de datos. Por ejemplo, ¿cuántos usuarios son de la India? No hay una manera fácil de saberlo, ya que esas direcciones no se normalizarán.

• Los usuarios pueden ingresar por error una dirección incompleta o simplemente incorrecta.

Para mitigar el primer problema, limite el campo a lo que cree que es un límite razonable. Personalmente, comenzaría con 1000 caracteres y luego lo reduciría según la longitud de las direcciones ingresadas por los primeros usuarios una vez que obtenga un conjunto de datos lo suficientemente grande.

Para mitigar los otros dos problemas, puede utilizar una API de terceros que analiza las direcciones y le presenta los datos que contienen el país, la ciudad, el código postal, etc. Si es posible, la API debería poder mostrar la dirección en un mapa para el usuario para reducir el riesgo de que el usuario ingrese una dirección incompleta o incorrecta: la mayoría de los usuarios saben dónde viven, y ver una posición diferente en un mapa les daría inmediatamente una pista de que deberían verificar su entrada.

Tenga en cuenta que cualquier API que use, no será perfecta. Encontrará la mayoría de las direcciones, pero no todas. Esto significa que si la API le dice que la dirección no existe, pero el usuario insiste en que sí, debe confiar a priori en el usuario, incluso si puede estar equivocado.

Esto también significa que aún debe almacenar la entrada del usuario original, junto con el resultado de la API. Esto significa que el esquema se convierte en:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

No hay uno

Cada país tiene diferentes formatos de dirección. Si tienes suerte, ¡y tienen un formato!

Obviamente, la latitud / longitud te dará un punto en el mundo, pero no es realmente útil para identificar casas individuales. Solo considere un bloque de torre, por ejemplo.

Su mejor opción es verificar el servicio postal de cada país para obtener un formato oficial. Esto puede ser excelente para su base de datos de back-end. Pero probablemente tendrá que simplificarlo para los usuarios finales, ya que contendrá muchos más campos de los que la mayoría de la gente está acostumbrada.

La del Reino Unido, por ejemplo, incluye cosas como 'localidad de doble dependencia', pero nadie sabría lo que eso significa si les preguntaras.

El único formato universal es tener un solo campo de texto que puede tener múltiples líneas de texto. Esto permitirá cualquier dirección posible en la tierra.

He estado desarrollando soluciones de software para ser utilizadas en muchos países. Abordamos este problema comenzando primero con la entidad más grande, es decir, el país tiene campos hasta el menos común o el más pequeño. Funciona bien para todos los países con los que hemos experimentado hasta ahora. También tenemos un sistema inteligente de prevención de duplicados y una fusión para aquellos que de alguna manera se han incorporado al sistema, ya que los usuarios son muy 'creativos'. En la sección de administración tenemos un orden de campo de dirección por configuración de país. es decir, Japón tiene el código postal / postal primero, donde el Reino Unido / EE. UU. es el último.

En general, usamos:

• País
• Publicar / código postal
• Estado / Provincia / Prefectura / Condado
• Ciudad pueblo Villa
• Calle / Carretera / Bloque
• Nombre / número del edificio
• Información específica / personalizada

Una vez ingresado y guardado, se puede mostrar una versión conjugada dejando fuera los campos que no son necesarios.

Como dije, esto funciona para todos los países en los que tenemos software y fue el resultado del desarrollo desde 1989.

Espero que esto ayude de alguna manera o al menos proporcione otra visión.

Como ya se dijo, el más universal (pero poco práctico para validar y quizás menos útil) es un solo campo grande Unicode.

Puede separar el país del resto de la dirección y almacenarlo como el código de país ISO. Normalizaría el país y ofrecería alguna utilidad para validar el resto de la dirección.

También puede separar el código postal, también conocido como código postal, del resto de la dirección. Esto también tendría alguna utilidad para validar el resto de la dirección, y podría ser útil (aunque impreciso) en la geolocalización. Por ejemplo: en Canadá puede identificar de manera única cualquier dirección especificando solo el código postal y el número de la calle (también conocido como número de casa); Esto puede no ser cierto en todos los países.

Dedicar campos a estados / provincias o ciudades comienza a ser más problemático debido a las variaciones en la forma en que cada país formula una dirección. He establecido tablas de direcciones que tienen esos campos porque la audiencia inicial está enfocada en América del Norte, sabiendo que un público internacional plantearía un problema. En la mayoría de los casos, se les puede "poner los cuernos", pero es un compromiso incómodo y potencialmente propenso a fallas, definitivamente no es universal.

Contrariamente a la respuesta de Mitchdav, recomendaría no usar la biblioteca de Google. Busqué en el repositorio varios lugares internacionales con esquemas de direccionamiento poco ortodoxos con la esperanza de encontrar datos de pruebas unitarias, pero preocupantemente encontré cero aciertos en todo el repositorio.

Creo que su mejor opción es tratar una dirección como texto de varias líneas de forma libre. Es una mierda que tal vez no pueda validar todas las direcciones, pero algunos formatos de direccionamiento son realmente extraños y posiblemente imprevistos y, al final, la responsabilidad de completar la dirección correcta recae en el usuario y en la mayoría de las aplicaciones el usuario tiene cualquier consecuencia negativa de completar un dirección inválida.

Quizás, tal vez, use un validador para proporcionar una advertencia , pero nada más que eso. Pero no rechace las direcciones que no validen, porque de lo contrario podría perder algunos clientes. Lo que lleva a la pregunta de cómo comunicar la advertencia al usuario de tal manera que se comunicará que, si el usuario vive en un área con un formato de dirección extraño, es seguro ignorar la advertencia ...

Como dices cualquier dirección en la tierra , solo hay una longitud larga o ...

https://what3words.com

Qué 3 palabras, es un algoritmo (por lo tanto, no una base de datos, por lo que puede integrarse en cualquier cosa) que puede definir un parche de 3x3 metros de cualquier lugar de la Tierra.

Tonga y algunos otros estados lo han adoptado como su sistema de código postal, aunque no lo reemplazará como una superposición, es genial, y está muy bien construido y pensado.