query fields example collection array mongodb mongodb-query document-database nosql

fields - mongodb select database



Almacenar nulo vs no almacenar la clave en absoluto en MongoDB (4)

De hecho, también tiene una tercera posibilidad: key: "" (valor vacío)

Y te olvidas de una especificidad sobre el valor nulo. Consulta en key: null recuperará todos los documentos donde la clave es nula o donde no existe la clave.

Cuando $exists:false una consulta en $exists:false recuperará solo doc donde la clave de campo no existe.

Para volver a su pregunta exacta, depende de sus consultas y qué datos representan. Si necesita mantener eso, por ejemplo, un usuario establece un valor y luego lo desactiva, debe mantener el campo como nulo o vacío. Si no lo necesita, puede eliminar este campo.

Me parece que cuando está creando un documento Mongo y tiene un campo {key, value} que a veces no va a tener un valor, tiene dos opciones:

  1. Escriba {key, null} es decir, escriba un valor nulo en el campo
  2. No guarde la clave en ese documento en absoluto

Ambas opciones son fácilmente consultables, en una consulta para {key : null} y en la otra consulta para {key : {$exists : false}} .

Realmente no puedo pensar en ninguna diferencia entre las dos opciones que tendrían algún impacto en un escenario de aplicación (excepto que la opción 2 tiene un poco menos de almacenamiento).

¿Puede alguien decirme si hay alguna razón por la que uno preferiría cualquiera de los dos enfoques sobre el otro, y por qué?

EDITAR

Después de formular la pregunta, también se me ocurrió que los índices pueden comportarse de manera diferente en los dos casos, es decir, se puede crear un índice disperso para la opción 2, pero todavía estoy tratando de comparar y entender cuáles serán las consideraciones del índice completo en los dos enfoques. .


Otro punto que quizás desee considerar es cuando usa herramientas OGM como Hibernate OGM.

Si está utilizando Java, Hibernate OGM es compatible con el estándar JPA. Entonces, si puede escribir una consulta de JPQL, sería teóricamente fácil si desea cambiar a un almacén de datos NoSQL alternativo que sea compatible con la herramienta OGM.

JPA no define un equivalente para $ existe en Mongo. Entonces, si tiene atributos opcionales en su colección, entonces no puede escribir un JPQL adecuado para el mismo. En tal caso, si el valor del atributo se almacena como NULO, aún es posible escribir una consulta JPQL válida como la que se muestra a continuación.

SELECT p FROM pppoe p where p.logout IS null;


Realmente se reduce a:

  • Tu escenario
  • Su manera de consulta
  • Tu índice necesita
  • Tu lenguaje

Yo personalmente he optado por almacenar claves nulas. Hace que sea mucho más fácil de integrar en mi aplicación. Utilizo PHP con Active Record y el uso de valores nulos hace que mi vida sea mucho más fácil, ya que no tengo que poner el estrés de la dependencia de campo en la aplicación. Además, no necesito hacer ningún código complejo para lidiar con las magias para establecer variables no existentes.

Personalmente, no almacenaría un valor vacío como "" ya que si no tiene cuidado podría tener dos valores vacíos null y "" y luego tendrá un tiempo de riesgo específico de consulta. Así que personalmente prefiero null para valores vacíos.

En cuanto al espacio y el índice: depende de cuántas filas no tengan esta columna, pero dudo que realmente note el aumento en el tamaño del índice debido a unos pocos documentos adicionales con nulo. Quiero decir que la diferencia en el almacenamiento es mínima, especialmente si el correspondiente El nombre clave es pequeño también. Eso va para configuraciones grandes también.

Estoy francamente inseguro de que el uso del índice entre $exists y null sin embargo, null podría ser un método más estandarizado para consultar la existencia, ya que recuerde que MongoDB no tiene esquemas, lo que significa que no tiene ningún requisito para tener ese campo en el documento que nuevamente produce Dos valores vacíos: inexistentes y null . Así que mejor elegir uno u otro.

Elijo null .


Tenga en cuenta que, dado que MongoDB no utiliza la compresión del diccionario de nombres de campo, field:null consume espacio en disco y RAM, mientras que no almacena ninguna clave en absoluto consume recursos.