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

Question

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

Locales (ID, LocationName, ParentID) donde las ubicaciones autónomas (como países, por ejemplo, EE. UU.) Son padres de sí mismos. De esta forma 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 recursión.

Agradecería cualquier otra recomendación o tal vez consejos sobre temas predecibles que estoy probable que se encuentre con un esquema de este tipo.

Answer 1

Es posible que desee echar un vistazo a Freebase.com como un sitio que haya tenido alguna discusión abierta acerca de lo que significa una "ubicación" y lo que significa cuando un lugar está señalado en otro. Este tipo de preguntas puede generar mucha discusión.

Por ejemplo, no es obvio "anidamiento geográfica", pero hay agrupamientos lógicos menos obvias. Por ejemplo, en un sentido estrictamente geográfico, la Ciudad del Vaticano está anidada dentro de Italia. Pero no está anidado políticamente. Del mismo modo, si su usuario está ubicado en un centro de investigación que pertenece a una universidad, pero no está ubicado en la propiedad de la Universidad, ¿modela esa relación o no?

Answer 2

Suena como un buen enfoque para mí. La única cosa que no tengo claro al leer tu publicación es qué significa "padres de sí mismos": si esto indica que la configuración regional no tiene un padre, es mejor que utilices un valor nulo que el ID de sí mismo.

Answer 3

Creo que podría estar pensando demasiado en esto. Hay una razón por la que la mayoría de los sistemas simplemente almacena direcciones y tal vez una tabla de países. Aquí hay algunas cosas a tener en cuenta:

1. ¿Sería una dirección en el Bronx incluir la ciudad como un nivel en la jerarquía? ¿Eliminaría una dirección en un área no incorporada el nivel de "ciudad" de la jerarquía? ¿Cómo modelas una dirección dentro de una universidad versus una dirección que no está dentro de una? Acabará con una jerarquía desigual que lo obligará a recorrer el árbol cada vez que necesite mostrar una dirección en su 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 incluso se tiene sólo una jerarquía. Brown University tiene instalaciones en Providence, Rhode Island y Bristol, Rhode Island. La única solución limpia sería tener una doble jerarquía con dos campus que pertenecen a sus respectivas ciudades en una jerarquía, pero que ambos pertenecen a la Universidad Brown en la otra jerarquía. (Una universidad es fundamentalmente a diferencia de una región de política. No debe realmente mezclarlas.)

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 líneas de estado. (De acuerdo a Wikipedia, al menos ...)

4. ¿Cómo va a introducir los datos? Construir la base de datos mediante el análisis de direcciones formateadas convencionalmente puede ser difícil si se tienen en cuenta direcciones de vanidad, nombres alternativos para ciertas calles, diferentes formatos internacionales, etc. Y creo que ingresar cada dirección jerárquicamente sería un PITA.

5. Parece que está intentando modelar todo el mundo en su aplicación. ¿Realmente desea o necesita mantener una tabla que podría concebir que contenga cada ciudad, estado, provincia, código postal y país del mundo? (¿O al menos todos en donde conoces a alguien?) Lo único que puedo pensar 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 agrega datos de latitud y longitud de Google.

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

Answer 4

Pensaré detenidamente sobre esto ya que puede no ser una característica necesaria. ¿Por qué no utilizar un campo de texto y dejar que los usuarios escriban una dirección?

Recuerde KISS principle (Keep It Simple, Stupid).

Answer 5

Aquí hay una sugerencia para un esquema bastante flexible. Advertir de forma inmediata: podría ser demasiado flexible/complejo para lo que realmente necesita

Ubicación (LocationID, LocationName) - bloque de construcción básico

LocationGroup (LocationGroupID, LocationGroupName, ParentLocationGroupID) - Este puede encapsular múltiples jerarquías. Usted tiene un nodo raíz y luego puede crear múltiples ramas independientes. P.ej. puede dividir por estado primero y luego crear varias sub-jerarquías, por ej. ZIP/city/xxxx

LocationGroupLocation (LocationID, LocationGroupID) - Así es como se vincula la ubicación con una o más jerarquías. P.ej. puede vincular su casa a un ZIP, así como a una ciudad ... Lo que necesita implementar es una restricción de que no debe poder enlazar una ubicación con dos jerarquías donde una de ellas es la matriz de la otra (como la relación ya está implícita).

Answer 6

Estoy de acuerdo con las otras publicaciones que debe tener mucho cuidado aquí acerca de sus requisitos. La ubicación puede convertirse en un problema complicado y esta es la razón por la cual los sistemas SIG son tan complicted.

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

• apoyo el comentario anterior que los elementos de nivel raíz no deben tener ellos mismos como a los padres. Los elementos de nivel de raíz deben tener un valor nulo para el elemento primario. Siempre tenga cuidado al colocar datos en un campo que no tiene ningún significado (es decir, un valor "especial" para no representar datos). Esta práctica rara vez es necesaria y manera se usa en exceso en la comunidad devleoper.
• Considera XPath/XML. Esto es Algo a tener en cuenta para molestarse en registrar la estructura de la jerarquía, y para procesar/analizar los datos en la recuperación. Si está utilizando el servidor MSSQL, las expresiones XPath en las sentencias de selección son perfectas para tareas como devolver la ruta completa de localización/jerarquía de un registro, ya que el código es simple y los resultados son rápidos.

Answer 7

Para las ubicaciones geográficas, es posible que desee resolver una dirección en una matriz de Latitud, Longitud (tal vez usando mapas de Google, etc.) para calcular proximidades, etc. Para la anidación geopolítica ... Iré con la respuesta KISS .

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

Answer 8

Estoy modelando una aplicación para usuarios globales y tengo los mismos problemas, pero creo que este enfoque ya podría estar en uso en muchas empresas. Pero, ¿por qué este problema no tiene una solución universal? O bien, ¿tiene este problema una mejor solución que puede ser el punto de partida o alguien en el mundo necesita pensar en una solución desde el principio? En TI, desafortunadamente hacemos las mismas cosas en cualquier momento y en muchos lugares. Por ejemplo, ¿quiénes no han creado más de un usuario, cliente o base de datos de productos? Y lo peor, todas las empresas del mundo lo han logrado. Creo que podría haber soluciones universales para problemas universales.