Estou tentando decidir sobre o design do banco de dados, com o mínimo possível de suposições (sobre como o aplicativo da Web realmente evolui) neste estágio.
Como primeiro passo, entendendo que JOINS são caros, estou considerando um pequeno número de tabelas monolíticas em oposição a um grande número de tabelas menores normalizadas. Como segundo ponto, estou confuso entre usar hstore vs. tabelas regulares vs. JSONB (com indexação GiST).
AFAIK (sinta-se à vontade para corrigir):
Geralmente, no Postgres, hstore é conhecido por ter um desempenho melhor do que outros tipos de dados. Esta apresentação do FOSDEM PGDAY tem algumas estatísticas interessantes (na segunda metade dos slides). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
Uma vantagem com hstore é a indexação rápida (GiN ou GiST). No entanto, com indexação JSONB, GiN e GiST também pode ser aplicada a dados JSON.
Este blog de um profissional do 2º Quadrante diz "Neste ponto provavelmente vale a pena substituir o uso do hstore pelo jsonb em todos os novos aplicativos" (vá até o final): http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-dynamic-columns/
Então, gostaria de decidir o seguinte:
- Para a parte principal (estruturada) dos dados: deve ir em algumas tabelas relacionais (relativamente grandes com muitas colunas) ou deve ser um número de armazenamentos de valor-chave usando hstore?
- Para os dados ad hoc (contribuídos pelo usuário/não estruturados), eles devem estar em armazenamentos de valor de chave JSON ou ad hoc em hstore (com as chaves armazenadas em uma das principais tabelas relacionais)?
Os bancos de dados relacionais são projetados em torno de junções e otimizados para fazê-los bem.
A menos que você tenha um bom motivo para não usar um projeto normalizado, use um projeto normalizado.
jsonbe coisas comohstoresão boas para quando você não pode usar um modelo de dados normalizado, como quando o modelo de dados muda rapidamente e é definido pelo usuário.Se você pode modelá-lo relacionalmente, modele-o relacionalmente. Se não puder, considere json etc. Se você estiver escolhendo entre json/jsonb/hstore, geralmente escolha jsonb, a menos que tenha um motivo para não fazê-lo.
Isso é o que eu disse na minha postagem no blog , que aborda apenas este tópico. Por favor, leia todo o post . O parágrafo que você citou aponta que, se você está escolhendo uma estrutura dinâmica, deve escolher jsonb em vez de hstore, mas o restante da postagem do blog é sobre por que você geralmente prefere modelar relacionalmente, se puder.
Então. Modele a parte estruturada principal relacionalmente. Se as tabelas forem muito largas com muitas colunas, isso pode ser um sinal de que é necessária mais normalização. Não tenha medo de junções. Aprenda a amar junções. Juntar muitas tabelas pequenas geralmente será mais rápido do que consultar e manter grandes tabelas desnormalizadas. Desnormalize apenas se precisar para casos específicos e, de preferência, por meio de visualizações materializadas ... mas não faça isso até que você saiba que precisa e tenha um problema concreto real para resolver.
Para dados de contribuição do usuário de forma livre e não estruturada, use jsonb. Ele deve funcionar tão bem quanto o hstore, mas é mais flexível e fácil de trabalhar.
Uma coisa relevante a entender: os índices GiST e GIN, como os usados no jsonb, geralmente são muito menos eficientes do que um índice b-tree simples. Eles são mais flexíveis, mas um índice de árvore b em uma coluna normal quase sempre será muito, muito mais rápido.