Mezclando tipos de geometría en una tabla PostGIS

23

Me enfrento con el siguiente problema. Tengo que migrar de la base de datos Oracle a PostgreSQL + PostGIS. Actualmente, todas las geometrías de todos los tipos se almacenan en una tabla y cada registro contiene un campo "tapa" que indica las características de la misma capa.

¿Cuáles son los pros y los contras de usar este método? ¿Debo dividir los datos en varias tablas si no necesito usar la base de datos con software de terceros? ¿Qué pasa con el rendimiento de las consultas espaciales, me ayudarán los índices?

    
pregunta drnextgis 25.06.2011 - 18:17

2 respuestas

24

Si no necesita asistencia de terceros y no ve la necesidad de consultar por tipo, mantenerlos en la misma tabla funciona bien. Alternativamente, puede usar un modelo de herencia como se explica en el capítulo 3 de PostGIS en acción.

enlace

Desde una perspectiva de la arquitectura, a PostGIS realmente no le importa si en una consulta se utilizan varios tipos diferentes. Si funcionó bien para usted en Oracle, será como si no tuviera un mejor desempeño en PostGIS.

Hay 2 razones para dividirlo (y se puede hacer más tarde si es necesario): 1) Evite que las personas inserten diferentes tipos que no desea, como colecciones de geometría, cadenas circulares y lo que no (lo que podría definir manualmente una restricción)

2) Si tienes mil millones de puntos y 1000 polígonos, y haces muchos puntos en las pruebas de polígonos, la velocidad es mucho mejor si cuando consultas y haces tu combinación, es contra mil millones, hasta 1000 registros. A diferencia de mil millones a mil millones de mesas récord Este sería el caso de cualquier base de datos espacial que creo (no específica de PostGIS). Supongo que también es cierto para todas las consultas relacionales (no específicas para consultas espaciales).

    
respondido por el LR1234567 27.06.2011 - 17:01
11

Este realmente me preocupa. Supongo que es porque he visto demasiados archivos CAD con datos en una sola capa, diferenciados solo por color.

Todo se reduce a una opción entre organizar los datos por estructura o por atributo .

Dada esa opción, siempre me gustaría organizar mis datos a través de la estructura de datos.

Para empezar, cuando procesas datos tienes un aro menos para saltar (por ejemplo, selecciona a, b, c de la tabla donde id = X en lugar de selecciona a, b, c de la tabla donde id = X AND lid = Y )

Luego, considere por qué las bases de datos permiten múltiples tablas: si un formato de datos ofrece estructuras de datos particulares, debe pensar que procesarán los datos de manera más eficiente si los usa.

Pero el gran problema (para mí) es cuando desea mover los datos a otro sistema. Entonces creo que se convierte en un verdadero desafío, porque la aplicación final podría no usar los datos de la misma manera. He visto a mucha gente desatenderse en este escenario.

En mi experiencia, podrá usar y transferir datos dos veces más eficientemente cuando tiene un modelo de datos decente (más profundo y más estructurado).

    
respondido por el Mark Ireland 27.06.2011 - 19:27

Lea otras preguntas en las etiquetas