Modelado de ubicaciones geográficas en una base de datos relacional

Question

Estoy diseñando un sistema de gestión de contactos y me he encontrado con un problema interesante relacionado con el modelado de ubicaciones geográficas de forma coherente.Me gustaría poder registrar ubicaciones asociadas con una persona en particular (direcciones postales del trabajo, la escuela, el hogar, etc.). Mi idea es crear una tabla de ubicaciones como la siguiente:

Configuraciones regionales (ID, nombre de ubicación, ID de padre) donde las ubicaciones autónomas (como países, p. ej.EE.UU.) son padres de sí mismos.De esta manera puedo tener un anidamiento arbitrariamente profundo de 'unidades políticas' (PAÍS > ESTADO > CIUDAD o PAÍS > ESTADO > CIUDAD > UNIVERSIDAD).Algunas consultas necesariamente implicarán recursividad.

Agradecería cualquier otra recomendación o tal vez consejo sobre problemas predecibles que probablemente encuentre con dicho esquema.

Answer 1

Es posible que desee echar un vistazo a Freebase.com como un sitio que ha tenido una discusión abierta sobre lo que significa una "ubicación" y lo que significa cuando una ubicación se incluye en otra.Este tipo de preguntas pueden generar mucha discusión.

Por ejemplo, existe el "anidamiento geográfico" obvio, pero hay anidamientos lógicos menos obvios.Por ejemplo, en un sentido estrictamente geográfico, la Ciudad del Vaticano está anidada dentro de Italia.Pero no está anidado políticamente.De manera similar, si su usuario está ubicado en un centro de investigación que pertenece a una universidad, pero no está ubicado en propiedad de la Universidad, ¿modela esa relación o no?

Answer 2

Me parece un buen enfoque.Lo único que no tengo claro al leer tu publicación es qué significa "padres de sí mismos"; si esto es para indicar que la configuración regional no tiene un padre, es mejor que uses null que el ID de sí mismo.

Answer 3

Creo que quizás estés pensando demasiado en esto.Hay una razón por la que la mayoría de los sistemas solo almacenan direcciones y tal vez una tabla de países.Aquí hay algunas cosas a tener en cuenta:

1. ¿Una dirección en el Bronx incluiría al municipio como un nivel en la jerarquía?¿Una dirección en un área no incorporada eliminaría el nivel de jerarquía de "ciudad"?¿Cómo se modela una dirección dentro de una universidad versus una dirección que no está dentro de una?Terminarás con una jerarquía irregular que te obligará a atravesar el árbol cada vez que necesites mostrar una dirección en tu aplicación.Si tiene una página de "libreta de direcciones", el impacto en el rendimiento podría ser significativo.

2. No estoy seguro de que tengas una sola jerarquía.La Universidad de Brown tiene instalaciones en Providence, RI y Bristol, RI.La única solución limpia sería tener una doble jerarquía con dos campus que pertenezcan cada uno a sus respectivas ciudades en una jerarquía pero que ambos pertenezcan a la Universidad de Brown en la otra jerarquía.(Una universidad es fundamentalmente diferente a una región política.Realmente no deberías mezclarlos.)

3. ¿Qué pasa con los códigos postales?Algunos códigos postales abarcan varias ciudades, otras veces una ciudad se divide en varios códigos postales.Y (raramente) algunos códigos postales incluso cruzan fronteras estatales.(Según Wikipedia, al menos...)

4. ¿Cómo introducirás los datos?Crear la base de datos analizando direcciones con formato convencional puede resultar difícil si se tienen en cuenta direcciones personalizadas, nombres alternativos para determinadas calles, diferentes formatos internacionales, etc.Y creo que ingresar cada dirección jerárquicamente sería un PITA.

5. Parece que estás intentando modelar el mundo entero en tu aplicación.¿Realmente desea o necesita mantener una tabla que pueda contener cada ciudad, estado, provincia, código postal y país del mundo?(¿O al menos todos los que conoces a alguien?) Lo único que se me ocurre que este esquema te compraría es la proximidad, pero si eso es lo que quieres, simplemente almacenaría el estado y el país por separado (y tal vez el código postal) y agregue datos de latitud y longitud de Google.

Perdón por el pesimismo extremo, pero yo mismo he recorrido ese camino.Es lógicamente hermoso y elegante, pero no funciona tan bien en la práctica.

Answer 4

Aquí hay una sugerencia para un esquema bastante flexible.Una advertencia inmediata:podría ser demasiado flexible/complejo para lo que realmente necesitas

Ubicación (ubicación, Nombre de ubicación) - Bloque de construcción básico

UbicationGroup (LocationGroupId, LocationGroupName, ParentLocationGroupId): esto puede encapsular las jerarquías múltiples.Tiene un nodo raíz y luego puede crear varias ramas independientes.P.ej.primero puede dividir por estado y luego crear varias subjerarquías, p.Código postal/ciudad/xxxx

UbicationGrouplocation (UbicationId, UbicationGroupId): así es como vincula la ubicación con una o más jerarquías.P.ej.puedes vincular tu casa a un ZIP, así como a una Ciudad...Lo que debe implementar es una restricción de que no debería poder vincular una ubicación con dos jerarquías cualesquiera donde una de ellas sea padre de la otra (ya que la relación ya está implícita).

Answer 5

Lo pensaría detenidamente ya que puede que no sea una característica necesaria.¿Por qué no utilizar simplemente un campo de texto y permitir que los usuarios escriban una dirección?

Recuerda el principio beso (Mantenlo simple, estúpido).

Answer 6

Estoy de acuerdo con las otras publicaciones en que debes tener mucho cuidado con tus requisitos.La ubicación puede convertirse en un tema complicado y es por eso que los sistemas SIG son tan complicados.

Si está seguro de que sólo necesita una estructura de jerarquía básica, tengo las siguientes sugerencias:

• Apoyo el comentario anterior de que los elementos de nivel raíz no deberían tenerse a sí mismos como padres.Los elementos del nivel raíz deben tener un valor nulo para el padre.Tenga siempre cuidado al colocar datos en un campo que no tiene significado (es decir,valor "especial" para no representar datos).Esta práctica rara vez es necesaria y forma usado en exceso en la comunidad de desarrolladores.
• Considere XPath/XML.Esto es algo a considerar si se molesta en registrar la estructura de la jerarquía y para procesar/analizar los datos en el momento de la recuperación.Si está utilizando MSSQL Server, las expresiones XPath en declaraciones seleccionadas son perfectas para tareas como devolver la ubicación completa/ruta de jerarquía de un registro, ya que el código es simple y los resultados rápidos.

Answer 7

Para ubicaciones geográficas, es posible que desee resolver una dirección en una matriz de latitud y longitud (tal vez usando mapas de Google, etc.) para calcular proximidades, etc.Para anidamiento geopolítico...Yo elegiría la respuesta de KISS.

Si realmente quieres modelarlo, quizás necesites que los tipos sean más genéricos…País -> Estado -> Condado -> Municipio -> Localidad -> Ciudad -> Suburbio -> Calle o apartado postal -> Número -> -> Apartamento, etc.-> Institución (Universidad o Empleador) -> División -> Subdivisión-1 -> subdivisión-n...¿Estás seguro de que no puedes hacer KISS?

Answer 8

Estoy modelando aplicaciones para usuarios globales y tengo los mismos problemas, pero creo que este enfoque ya podría usarse en muchas empresas.Pero ¿por qué este problema no tiene una solución universal?¿O tiene este problema una mejor solución que pueda ser el punto de partida o alguien en el mundo necesita pensar en una solución desde el principio?Desafortunadamente, en TI, hacemos lo mismo en cualquier momento y en muchos lugares.Por ejemplo, ¿quiénes no han creado más de una base de datos de usuarios, clientes o productos?Y lo peor, todas las empresas del mundo lo han conseguido.Creo que eso podría tener soluciones universales para problemas universales.