Mezcla de tipos de geometría en una tabla PostGIS

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 de "tapa" que indica las características de la misma capa.

¿Cuáles son los pros y los contras de usar tal 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?

Si no necesita soporte de terceros y no prevé la necesidad de consultar por tipo, mantenerlos en la misma tabla funciona bien. Alternativamente, podría usar un modelo de herencia como se discutió en el capítulo 3 de PostGIS en acción.

http://www.postgis.us/chapter_03_edition_1

Desde una perspectiva de arquitectura, a PostGIS realmente no le importa si en una consulta se usan varios tipos diferentes. Si funcionó bien para usted en Oracle, será como si no fuera mejor en PostGIS.

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

2) Si tiene mil millones de puntos y 1000 polígonos, y hace muchos puntos en las pruebas de polígonos, la velocidad es mucho mejor si consulta y hace su unión, es contra mil millones, a 1000 tablas de registro en lugar de una tabla de registro de mil millones a mil millones. Este sería el caso de cualquier base de datos espacial, creo (no específica de PostGIS). Es cierto para todas las consultas relacionales, supongo que también (no específico para consultas espaciales).

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

En realidad, se trata de elegir entre organizar los datos por estructura o por atributo .

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

Para empezar, cuando procesa datos tiene un aro menos para saltar (por ejemplo, seleccione a, b, c de la tabla donde id = X en lugar de seleccionar 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 datos de la misma manera. He visto a muchas personas despegarse en este escenario.

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