O PostgreSQL 9.2 introduziu o jsontipo de campo. Por que e quando devo usá-lo? Quais benefícios ele tem sobre um campo de texto?
Eu pensei que havia novas opções de consulta disponíveis, no entanto, eu não vi nenhuma. Estou esquecendo de algo?
O PostgreSQL 9.2 introduziu o jsontipo de campo. Por que e quando devo usá-lo? Quais benefícios ele tem sobre um campo de texto?
Eu pensei que havia novas opções de consulta disponíveis, no entanto, eu não vi nenhuma. Estou esquecendo de algo?
Respostas:
O benefício do novo recurso é duplo. As colunas do tipojson verificam a validade de seu conteúdo para que o conteúdo da coluna seja JSON automaticamente válido e você receberá um erro se tentar gravar mais alguma coisa nele.
E você tem funções básicas para criar JSON válido em tempo real a partir de linhas ou matrizes - que é um caso de uso muito comum.
Cito Andrew Dunstan na lista pgsql-hackers :
Em algum momento, possivelmente haverá algumas funções de processamento de json (em oposição à produção de json), mas não na 9.2.
Eu usei essa citação antes nesta pergunta relacionada ao SO .
.. finalmente traz uma série de funções e operadores. Confira a página de manual para funções JSON .
Resposta relacionada no SO:
@Will colocar post no blog. Veja o comentário abaixo.
Certifique-se de verificar o novo jsonbtipo com uma série de novas funcionalidades.
Acima de tudo, o armazenamento binário decomposto permite um armazenamento menor no disco e um operador de igualdade para jsonb(ao contrário json), o que possibilita várias operações adicionais (como DISTINCTum UNIQUEíndice).
Ainda mais funções foram adicionadas para ambos jsone jsonb. json_to_record(), json_to_recordset()etc. Mais nas notas de versão.
Em poucas palavras, o tipo de dados JSON (e a extensão e o tipo de dados HSTORE mais antigos também) permitem usar o PostgreSQL como um armazenamento de dados "sem esquema" (ou combinar dados relacionais e não relacionais "sem esquema"), em vez de tendo que recorrer a algumas das outras opções do NoSQL (como o MongoDB). Você ainda ganha algumas coisas que não pode fazer com o MongoDB, como indexação filtrada, indexação de expressões etc. A única desvantagem é que o PostgreSQL não suporta sharding out-of-the-box como o MongoDB ... no entanto, eu realmente questione com que freqüência o sharding é realmente necessário. Com um banco de dados PostgreSQL 9.3 bem configurado, recursos suficientes de O / S e alguns índices de expressão filtrada razoavelmente bem pensados, você deve conseguir facilmente recuperações de linha sem esquema no intervalo de 0,25 milissegundos.
Dave Sisk HTH
Basicamente, vejo três casos de uso aqui:
O primeiro pode ser feito diretamente do PostgreSQL sem a necessidade de complementos. Você deve ser capaz de fazer algo como:
SELECT row_to_json(mt.id, mt.testval, array_agg(mt2))
FROM my_table mt
JOIN my_table2 mt2 ON mt.id = mt2.mt_id
WHERE mt.id = 123;Isso pode ser usado para criar matrizes aninhadas etc. na sua saída e evitar muitos problemas de análise confusos no lado do aplicativo.
o segundo está passando dados complexos para o banco de dados para processamento. Atualmente, não há funções internas para facilitar isso, mas com complementos como pl / v8js, você pode programar seu banco de dados em Javascript e usar json como um formato de troca. Isso pode permitir a criação de interfaces mais ricas dentro do seu banco de dados. Observe que, como você pode indexar saídas de função, você pode usá-lo para criar índices de aspectos do JSON a serem armazenados no seu db.
A terceira é uma área em que planejamos usá-la no LedgerSMB. A idéia é que talvez desejemos permitir que os integradores de sistemas armazenem informações muito simples junto com as contas dos clientes. Isso poderia ser compactado em um campo JSON que seria armazenado. Isso não poderia ser consultado diretamente pelos aplicativos principais, mas se o pessoal quisesse adicionar isso usando o pl / v8js, isso poderia ser feito para empresas individuais que usam o software.