Inserir documento JSON com `.` na chave do MongoDB

Em primeiro lugar, isso é mais uma questão de design do que uma questão de programação.

Estou criando um aplicativo no qual tenho que buscar dados JSON existentes e inseri-los no MongoDB. Descobri que alguns dos documentos JSON têm um período .em sua chave. Li na documentação do MongoDB que períodos .não são permitidos como chaves no MongoDB, pois são usados ​​para consulta.

Eu não faço muitas inserções nos aplicativos Web, é praticamente uma inserção única. Além disso, eu geralmente recuperava o documento inteiro em vez de procurar por partes dele, pois preciso obter todos os dados.

Portanto, considerando meus requisitos, tenho duas opções sobre como armazenar o documento JSON:

1. Pesquise no JSON o período nas chaves e escape-as e insira-as no MongoDB.
2. Converta todo o JSON no formato BSON e armazene-o como tal, evitando assim a necessidade de escape, e analise manualmente o JSON quando necessário fora do MongoDB

Você poderia me dizer qual seria um projeto melhor, pois não consigo chegar a uma conclusão.

Existem algumas alternativas:

1. Substitua os pontos por um traço.

Essa seria minha abordagem favorita, pois mantém a estrutura explícita o suficiente.

Como, de acordo com você, “é praticamente uma inserção única”, deve ser relativamente simples verificar se não quebra nada (ou seja, já existe uma mesma chave com um traço). Para outras situações, fazer essas verificações programaticamente requer escrever algum código, mas ainda é uma tarefa relativamente fácil.

2. Substitua os pontos por um caractere de ponto Unicode, como U + FF0E .

Eu recomendaria fortemente contra essa abordagem, pois levaria a enormes dores de cabeça de depuração no caminho . Deixar alguém que usa o JSON resultante em algum lugar do código distante do MongoDB adivinhar que um ponto não é realmente um ponto é uma boa maneira de perder literalmente semanas do tempo de alguém. Mantenha esses truques Unicode para os hackers que desejam induzir alguém a pensar que um personagem é diferente.

3. Use BSON.

Como você alega que "recuperaria o documento inteiro em vez de consultar partes dele", essa abordagem não apresenta grandes desvantagens no seu caso . Embora você tenha dito "principalmente", o que significa que, às vezes, você recuperará apenas partes do documento.

Em geral, a desvantagem é que você não poderá pesquisar no documento ou carregar apenas uma parte dele.

4. Use uma codificação padrão, como Base64.

Converter as chaves problemáticas (ou todas as chaves, dependendo da proporção entre problemáticas e não problemáticas) para Base64 ou hexadecimal pode ser uma solução viável, com o benefício de ser bastante explícito: a maioria dos desenvolvedores reconheceria rapidamente os valores Base64 ou hexadecimais .

A desvantagem é o aumento da pegada de memória, bem como a necessidade de codificar e decodificar as chaves ao usá-las.

5. Defina check_keyscomo false.

Eu desaconselharia fortemente essa abordagem, pois isso tornaria a consulta de dados ambígua e gastaria horas ou dias tentando descobrir por que uma consulta específica não faz o que você imaginava que deveria estar fazendo. Dot é um personagem reservado e o cheque está aqui para protegê-lo; dizendo ao MongoDB para ignorar a verificação, você apenas adiará o momento em que precisará lidar com um conflito entre a sintaxe do MongoDB e o caractere reservado usado em uma chave.

Basta usar o BSON. Então você tem um formato bem documentado, com suporte à biblioteca bem testado e, o mais importante, pode invertê-lo (codificar / decodificar) sem perda.