Misturando tipos de geometria em uma tabela PostGIS

Estou diante do seguinte problema. Eu tenho que migrar do banco de dados Oracle para PostgreSQL + PostGIS. Atualmente, todas as geometrias de todos os tipos são armazenadas em uma tabela e cada registro contém um campo "tampa" que indica características da mesma camada.

Quais são os prós e os contras de usar esse método? Devo dividir dados em várias tabelas se não precisar usar o banco de dados com software de terceiros? E quanto ao desempenho de consultas espaciais, os índices me ajudarão?

Se você não precisar de suporte de terceiros e não prever a necessidade de consultar por tipo, mantê-los na mesma tabela funciona bem. Como alternativa, você pode usar um modelo de herança conforme discutido no capítulo 3 do PostGIS in Action.

http://www.postgis.us/chapter_03_edition_1

Do ponto de vista da arquitetura, o PostGIS realmente não se importa se em uma consulta vários tipos diferentes são usados. Se o desempenho for bom para você no Oracle, será como se não tivesse melhor desempenho no PostGIS.

Existem 2 razões para dividir (e podem ser feitas posteriormente, conforme necessário): 1) Impedir que as pessoas insiram tipos diferentes que você não deseja, como coleções de geometria, seqüências de caracteres circulares e outras não (que você pode definir manualmente uma restrição )

2) Se você possui um bilhão de pontos e 1000 polígonos e faz muitos pontos nos testes de polígono, a velocidade é muito melhor se quando você consultar e fizer sua junção - contra um bilhão - a tabela de registros de 1000 em oposição a tabela de um bilhão a bilhão de registros. Esse seria o caso de qualquer banco de dados espacial que eu acho (não específico do PostGIS). Também é verdade para todas as consultas relacionais (não específicas para consultas espaciais).

Este realmente me incomoda. Acho que é porque vi muitos arquivos CAD com dados em uma camada, diferenciados apenas pela cor.

O que se resume é realmente uma escolha entre organizar os dados por estrutura ou por atributo .

Dada essa escolha, eu sempre organizaria meus dados por meio da estrutura de dados.

Para começar, ao processar dados, você tem menos um bastidor para percorrer (por exemplo, selecione a, b, c na tabela em que id = X em vez de selecionar a, b, c na tabela em que id = X AND lid = Y )

Em seguida, considere por que os bancos de dados permitem várias tabelas - se um formato de dados oferece estruturas de dados específicas, você deve pensar que processará os dados com mais eficiência se você os usar.

Mas o grande problema (para mim) é quando você deseja mover os dados para outro sistema. Então, acho que isso se torna um desafio real, porque o aplicativo final pode não usar os dados da mesma maneira. Eu já vi tantas pessoas se soltarem nesse cenário.

Portanto, na minha experiência, você poderá usar e transferir dados duas vezes mais eficientemente quando houver um modelo de dados decente (mais profundo e mais estruturado).