O PostgreSQL possui um módulo chamado hstore que implementa o uso de pares de chave / valor (é algo como o modelo OpenStreetMap, mas em uma única tabela).
Quais são os prós e os contras do hstore em relação às compatibilidade com GIS, adição e recuperação de dados?
varcharlista delimitada por vírgula:'name=foo,type=bar,'E recupere valores com: #SELECT * WHERE tags LIKE '%type=bar,%'Respostas:
Na verdade, demonstramos isso em nosso livro (que supostamente será impresso na próxima semana). No capítulo 3. Você pode baixar o código aqui: http://www.postgis.us/chapter_03
(e, claro, se você comprar o nosso livro, obterá explicações completas sobre os prós e contras)
Ele usa o comutador osm2pgsql hstore para importar tags osm como coluna hstore.
O que fazemos para compensar o fato de o Quantum e outras coisas não suportarem diretamente o hstore é criar uma visão em torno das principais tags necessárias. Para aplicativos em que você tem controle completo, usando uma consulta com o apelido de key-> value como uma coluna, também funciona bem mesmo se o driver do banco de dados não entender o tipo hstore.
fonte
Prós:
É uma chave / valor flexível e de alto desempenho que pode ser indexado e consultado.
Eu tenho um GIS da web sem esquema complexo que usa uma coluna HStore para armazenar as propriedades dos recursos.
Contras:
Como a maioria das ferramentas WMS / WFS, como Mapserver, Geoserver e similares, não podem entender e trabalhar com colunas HStore, você acaba criando visualizações SQL codificadas (no Geoserver, pelo menos). Você ainda pode usá-lo para trabalhar com WMS / WFS, mas como você precisa codificar as chaves, perde os recursos sem esquema.
fonte
Eu mesmo não tenho experiência com isso, mas se você estiver interessado em armazenar dados espaciais em um banco de dados, convém procurar nosql espacial. Na postagem, encontrei, por exemplo: /programming/2041622/nosql-and-spatial-data
fonte