Isso sempre foi possível com o MongoDB porque sempre houve a capacidade de construir condições de consulta usando Avaliação de JavaScript :
db.attrs.find(function() {
var attrs = this.attrs;
return Object.keys(attrs).some(function(key) {
return attrs[key].value === "14"
});
})
Onde isso retornará corretamente os documentos que correspondem à condição aqui, pesquisando as possíveis chaves no documento pelo valor necessário.
Mas não é realmente uma pergunta sobre "possível", mas mais uma de "essa é realmente uma boa ideia" , para o qual a resposta básica é "Não".
Bancos de dados são bestas inconstantes que gostam de otimizar com coisas como índices e afins, bem como seu próprio conjunto de operadores esperado para tornar a pesquisa o mais eficiente possível. Então, sim, você pode passar por um interpretador de linguagem que efetivamente avalia uma condição codificada em cada documento ou pode reconsiderar seu padrão de design.
Os bancos de dados adoram "ordem", então dê um pouco, pois há uma simples reestruturação organizada dos dados que você propõe:
{
"attrs" : [
{ "key": "A1", "type" : "T1", "value" : "13" },
{ "key": "A2", "type" : "T2", "value" : "14" }
]
}
Organizada dessa forma, a consulta se torna tão simples quanto:
db.attrs.find({ "attrs.value": "14" })
E, claro, pode suportar e usar um índice em qualquer uma dessas propriedades do subdocumento na matriz.
O MongoDB é, afinal, um "banco de dados" e, como todos os bancos de dados, está mais preocupado com os "valores" de suas propriedades, em vez de pesquisar usando os nomes de suas "chaves". Portanto, coisas que representam "dados" significativos não devem fazer parte do nome de uma "chave", mas devem ser o "valor" de uma "chave" como um "identificador", conforme demonstrado acima.
Ter um caminho consistente para os dados que você deseja consultar é a maneira ideal de trabalhar com dados dentro do MongoDB. Usar uma estrutura em que os nomes das chaves mudam constantemente, não pode ser percorrido por nada além de código em execução, e isso é muito mais lento e pior para o desempenho do que usar as operações nativas e facilidades como índices.
