Soy bastante nuevo en el mundo de firebase/backend. Empecé a aprender recientemente. Así que he decidido hacer un proyecto de muestra para aprender. El proyecto se parece más a un perfil de trabajo como LinkedIn/Smartr. Estoy luchando para tomar una decisión sobre cómo debo estructurar mi base de datos.
Estoy usando Angular 13 en la interfaz y Firebase(@angular/fire) como backend.
Entonces, el proyecto que estoy tratando de construir es muy simple. Tendrá información básica de un usuario, como firstName , lastName , age , title , location . Estos son los datos básicos que serán necesarios para completar un perfil.
Entonces, en Firestore , hice una colección llamada Usuarios donde para cada usuario tiene una identificación de documento que se genera con la siguiente información.
{ age: 23, email: "demo.user@mail.com", firstName: "Demo", lastName: "User", title: "Engineer" location: "USA" uid: "232dsf23" }El sistema también contará con un sistema de autenticación. Usando el sistema de autenticación Firebase ya definido.
Entonces, el uid que mantengo es la id que obtengo en respuesta después de que un usuario se registra. Lo estoy usando como ID de documento de Users .
Hasta ahora he hecho esto. Entonces, lo siguiente que quiero agregar en mi proyecto de demostración es la sección Experiencia laboral .
La funcionalidad funcionará exactamente como vemos en LinkedIn/Smartr . Un usuario solo puede agregar/editar solo una experiencia laboral a la vez mediante un modal/diálogo.
Entonces mis consultas son:
¿Debo incluir workExperience una nueva propiedad de objeto en cada documento de la colección de users ? Si mantengo una nueva propiedad llamada workExperience en los documentos de la colección de users , necesitaré una identificación con cada experiencia si no me equivoco porque un usuario puede editar/actualizar solo una experiencia a la vez. Entonces, dado que Firebase no es compatible con la identificación incremental automática (por lo que leí), ¿cómo debo abordarlo?
Si hago una colección separada llamada work-experience donde agregar una nueva experiencia creará un nuevo documento en esa colección para cada usuario, ¿cómo conectaría qué experiencia está relacionada con qué usuario? Y cómo debo consultar para obtener los datos esperados.
¿Qué procedimiento debo seguir? Si tiene alguna otra sugerencia sobre cómo debería abordarlo, por favor sugiera.
La respuesta depende en gran medida de cómo muestre estos datos en su interfaz.
Si planea mostrar en la misma pantalla la información básica del usuario y la experiencia laboral , lo mejor es agregar la experiencia laboral al documento Firestore del usuario: solo ejecuta una consulta para esta pantalla.
Por otro lado, si planea mostrar primero una pantalla con la información básica del usuario que tiene un enlace/botón para abrir otra pantalla que muestre la experiencia laboral, entonces tiene sentido almacenar los datos de la experiencia laboral en otro documento. Consulta estos datos solo cuando el usuario final decide mostrarlos.
Para eso, puede tener una "colección separada llamada work-experience " como mencionó, y para cada usuario usa el ID de usuario como la ID del Documento Firestore de experiencia laboral (puede muy bien reutilizar la misma ID de Documento en diferentes colecciones). De esta manera, es muy fácil consultar el documento de experiencia laboral de un usuario específico: simplemente cambie el nombre de la colección en su consulta.
- users (collection) - userId1 (doc) - userId2 (doc) ... - work-experiences (collection) - userId1 (doc) - userId2 (doc) ...Si planea tener algunas secciones adicionales similares a la sección de experiencia laboral , por ejemplo, educación o pasatiempos , puede usar el mismo enfoque.
- users (collection) - userId1 (doc) - userId2 (doc) ... - work-experiences (collection) - userId1 (doc) - userId2 (doc) ... - educations (collection) - userId1 (doc) - userId2 (doc) ... - hobbies (collection) - userId1 (doc) - userId2 (doc) ... Pero otro enfoque interesante es tener, para cada usuario, una subcolección llamada, por ejemplo details-sections , donde almacena esos documentos con una identificación fija:
- users (collection) - userId1 (doc) - details-sections (sub-collection) - work-experience (doc) - education (doc) - hobbies (doc) - userId2 (doc) - details-sections (sub-collection) - work-experience (doc) - education (doc) - hobbies (doc)La principal ventaja de este modelo de datos es que es fácil navegar a los datos de un usuario desde la consola de Firebase. Desde una perspectiva de costo o rendimiento de consultas, es exactamente similar al modelo de datos anterior. Las reglas de seguridad son un poco diferentes entre los dos modelos, pero nada que realmente influya en la elección entre esos dos modelos.