java - ¿Cuál es la forma correcta de estructurar este tipo de datos en Firestore?

firebase firebase-realtime-database

Question

He visto videos y leí la documentación de Cloud Firestore, del servicio Google Firebase, pero no puedo entender esto en una base de datos en tiempo real.

Tengo en mente esta aplicación web en la que quiero almacenar a mis proveedores de diferentes categorías de productos. Quiero realizar una consulta de búsqueda en todos mis productos para encontrar qué proveedores tengo para ese producto y, finalmente, acceder a la información de ese proveedor.

Estoy planeando usar esta estructura para este propósito:

Providers ( Collection )
   Provider 1 ( Document )
      Name
      City
      Categories
   Provider 2
      Name
      City

Products ( Collection )
   Product 1 ( Document )
      Name
      Description
      Category
      Provider ID
   Product 2
      Name
      Description
      Category
      Provider ID

Entonces, mi pregunta es: ¿es este enfoque la forma correcta de acceder a la información del proveedor una vez que obtengo el producto que deseo?

Sé que esto es posible en la base de datos en tiempo real, utilizando el ID de proveedor que podría buscar ese proveedor en la sección de proveedores, pero con Firestore no estoy seguro si es posible o si este es el enfoque correcto.

Answer 1

¿Cuál es la forma correcta de estructurar este tipo de datos en firestore?

Debe saber que no existe una solución "perfecta", "la mejor" o "la correcta" para estructurar una base de datos de Cloud Firestore. La solución mejor y correcta es la solución que se adapta a sus necesidades y le facilita el trabajo. También tenga en cuenta que tampoco existe una única "estructura de datos correcta" en el mundo de las bases de datos NoSQL. Todos los datos se modelan para permitir los casos de uso que requiere su aplicación. Esto significa que lo que funciona para una aplicación puede ser insuficiente para otra aplicación. Así que no hay una solución correcta para todos. Una estructura efectiva para una base de datos de tipo NoSQL es completamente dependiente de cómo desea consultarla.

La forma en que está estructurando sus datos, me parece bien. En general, hay dos formas en las que se puede lograr lo mismo. La primera sería mantener una referencia del proveedor en el objeto del producto (como ya lo hizo) o copiar todo el objeto del proveedor dentro del documento del producto. Esta última técnica se llama denormalization y es una práctica bastante común cuando se trata de Firebase. Por lo tanto, a menudo duplicamos datos en las bases de datos nosql, para satisfacer consultas que de otra forma no serían posibles. Para una mejor comprensión, te recomiendo que veas este video, la desnormalización es normal con la base de datos de Firebase . Es para la base de datos en tiempo real de Firebase, pero los mismos principios se aplican a Cloud Firestore.

Además, cuando estás duplicando datos, hay una cosa que debes tener en cuenta. De la misma forma en que agrega datos, debe mantenerlos. En otras palabras, si desea actualizar / eliminar un objeto proveedor, debe hacerlo en cada lugar que exista.

Puede que te preguntes ahora, cuál es la mejor. En un sentido muy general, la mejor manera en que puede almacenar referencias o datos duplicados en una base de datos NoSQL es completamente dependiente de los requisitos de su proyecto.

Por lo tanto, debe hacerse algunas preguntas sobre los datos que desea duplicar o simplemente mantenerlos como referencias:

1. ¿Es la estática o cambiará con el tiempo?
2. Si es así, ¿necesita actualizar cada instancia duplicada de los datos para que todos permanezcan sincronizados? Esto es lo que también he mencionado anteriormente.
3. Cuando se trata de Firestore, ¿está optimizando el performance o el cost ?

Si sus datos duplicados necesitan cambiar y permanecer sincronizados al mismo tiempo, es posible que en el futuro tenga dificultades para mantener actualizados todos esos duplicados. Esto también puede implicar que gaste una gran cantidad de dinero para mantener todos esos documentos actualizados, ya que requerirá una lectura y escritura de cada documento para cada cambio. En este caso, la celebración de referencias será la variante ganadora.

En este tipo de enfoque, usted escribe muy pocos datos duplicados (prácticamente solo la Provider ID del Provider ID ). Eso significa que su código para escribir estos datos será bastante simple y rápido. Pero al leer los datos, deberá cargar los datos de ambas colecciones, lo que significa una llamada de base de datos adicional. Este no suele ser un gran problema de rendimiento para una cantidad razonable de documentos, pero definitivamente requiere más código y más llamadas a la API.

Si necesita que sus consultas sean muy rápidas, puede preferir duplicar más datos para que el cliente solo tenga que leer un documento por elemento consultado, en lugar de varios documentos. Pero también puede depender de los cachés de clientes locales, lo que hace que sea más barato, dependiendo de los datos que el cliente tenga que leer.

En este enfoque, usted duplica todos los datos de un provider para cada documento de product . Esto significa que el código para escribir estos datos es más complejo, y definitivamente está almacenando más datos, un objeto de proveedor más para cada documento de producto. Y tendrá que averiguar si y cómo mantenerlo actualizado en cada documento. Pero, por otro lado, leer un documento del product ahora le brinda toda la información sobre el documento del provider en una sola lectura.

Esta es una consideración común en las bases de datos NoSQL: a menudo tendrá que considerar el rendimiento de escritura y el almacenamiento en disco frente al rendimiento de lectura y la escalabilidad.

Para su elección de si desea o no duplicar algunos datos, depende en gran medida de sus datos y sus características. Tendrá que pensar en cada caso.

Entonces, al final, recuerde que ambos son enfoques válidos, y ninguno de ellos es mejor que el otro. Todo depende de cuáles sean sus casos de uso y de su comodidad con esta nueva técnica de duplicación de datos. La duplicación de datos es la clave para lecturas más rápidas, no solo en la base de datos en tiempo real de Cloud Firestore o Fireabase sino en general. Cada vez que agrega los mismos datos a una ubicación diferente, está duplicando los datos en favor de un rendimiento de lectura más rápido. Desafortunadamente, a cambio, tiene una actualización más compleja y un mayor uso de almacenamiento / memoria. Pero debe tener en cuenta que las llamadas adicionales en la base de datos en tiempo real de Firebase no son caras, en Firestore son. La cantidad de datos de duplicación en comparación con las llamadas a bases de datos adicionales es óptima para usted, depende de sus necesidades y de su disposición para dejar de lado la "mentalidad de punto único de definición", que puede denominarse muy subjetiva.

Después de terminar algunos proyectos de Firebase, encuentro que mi código de lectura se simplifica drásticamente si duplico datos. Pero, por supuesto, el código de escritura se vuelve más complejo al mismo tiempo. Es una compensación entre estos dos y sus necesidades lo que determina la solución óptima para su aplicación. Además, para ser aún más preciso, también puede medir lo que está sucediendo en su aplicación utilizando las herramientas existentes y decidir en consecuencia. Sé que esa no es la recomendación concreta pero eso es un desarrollo softwarte. Todo se trata de medir cosas.

Recuerde también que algunas estructuras de base de datos son más fáciles de proteger con algunas reglas de seguridad. Así que trate de encontrar un esquema que se pueda asegurar fácilmente utilizando las Reglas de seguridad de Cloud Firestore .

Por favor, eche un vistazo a mi respuesta de este post donde he explicado más sobre collections , maps y arrays en Firestore.