Insertar documento JSON con `.` en clave para MongoDB

En primer lugar, se trata más de una pregunta de diseño que de una pregunta de programación.

Estoy creando una aplicación donde tengo que buscar datos JSON existentes e insertarlos en MongoDB. Descubrí que algunos de los documentos JSON tienen un punto .en su clave. Leí en la documentación de MongoDB que los períodos .no están permitidos como claves en MongoDB, ya que se utilizan para realizar consultas.

No hago muchas inserciones en las aplicaciones web, es casi una inserción única. Además, en su mayoría recuperaría todo el documento en lugar de consultar partes del mismo, ya que necesito obtener todos los datos.

Entonces, teniendo en cuenta mis requisitos, tengo dos opciones sobre cómo almacenar el documento JSON:

1. Busque en el JSON el punto en las teclas y escape y luego insértelos en MongoDB.
2. Convierta todo el JSON en formato BSON y guárdelo como tal, evitando así la necesidad de escapar, y analice manualmente el JSON cuando sea necesario fuera de MongoDB

¿Podría decirme cuál sería un mejor diseño, ya que no puedo llegar a una conclusión?

Hay algunas alternativas:

1. Reemplace los puntos por un guión.

Este sería mi enfoque favorito, ya que mantiene la estructura lo suficientemente explícita.

Dado que, según usted, "es una inserción casi única", debería ser relativamente simple verificar si no rompe nada (es decir, ya hay una misma clave con un guión). Para otras situaciones, hacer esas comprobaciones mediante programación requiere escribir algo de código, pero sigue siendo una tarea relativamente fácil.

2. Reemplace los puntos por un carácter de punto Unicode como U + FF0E .

Aconsejaría encarecidamente este enfoque, ya que conduciría a dolores de cabeza de depuración masiva en el futuro . Dejar que alguien que usa el JSON resultante en algún lugar del código, lejos de MongoDB, adivine que un punto no es realmente un punto es una buena manera de perder literalmente semanas del tiempo de alguien. Mantenga esos trucos Unicode para los hackers que quieren engañar a alguien para que piense que un personaje es diferente.

3. Use BSON.

Como usted afirma que "en su mayoría recuperaría el documento completo en lugar de consultar partes del mismo", este enfoque no tiene inconvenientes importantes en su caso . Sin embargo, usted dijo "en su mayoría", lo que significa que a veces, solo recuperará partes del documento.

En general, el inconveniente es que no podrá buscar en el documento ni cargar solo una parte del mismo.

4. Use una codificación estándar, como Base64.

Convertir las claves problemáticas (o todas las claves, dependiendo de la relación entre las problemáticas y las no problemáticas) a Base64 o hexadecimal podría ser una solución viable, con el beneficio de ser bastante explícito: la mayoría de los desarrolladores reconocerían los valores de Base64 o hexadecimal de un vistazo .

El inconveniente es el aumento de la huella de memoria, así como la necesidad de codificar y decodificar las teclas cuando se usan.

5. Establezca check_keysen false.

Aconsejaría encarecidamente este enfoque, ya que esto haría que la consulta de datos fuera ambigua y desperdiciara horas o días tratando de descubrir por qué una consulta específica no hace lo que imaginaba que debería estar haciendo. Dot es un personaje reservado y el cheque está aquí para protegerlo; Al decirle a MongoDB que omita la comprobación, solo pospondrá el momento en que tendrá que lidiar con un conflicto entre la sintaxis de MongoDB y el carácter reservado utilizado en una clave.

Solo usa BSON. Entonces tiene un formato bien documentado, con soporte de biblioteca bien probado, y lo más importante, puede invertirlo (codificar / decodificar) sin pérdida.