Si hallas algún problema en tu código o trabajo, recuerda probar siempre en un entorno de testing antes subir el código al proyecto final.
Solución:
ACTUALIZAR: Ahora hay un documento sobre la estructuración de datos. Además, vea esta excelente publicación sobre estructuras de datos NoSQL.
El problema principal con los datos jerárquicos, a diferencia de RDBMS, es que es tentador anidar datos porque podemos hacerlo. En general, desea normalizar los datos hasta cierto punto (tal como lo haría con SQL) a pesar de la falta de consultas y declaraciones de combinación.
También desea desnormalizar en lugares donde la eficiencia de lectura es una preocupación. Esta es una técnica utilizada por todas las aplicaciones a gran escala (p. ej., Twitter y Facebook) y, aunque va en contra de nuestros principios DRY, generalmente es una característica necesaria de las aplicaciones escalables.
La esencia aquí es que desea trabajar duro en las escrituras para facilitar las lecturas. Mantenga los componentes lógicos que se leen por separado (por ejemplo, para las salas de chat, no coloque los mensajes, la metainformación sobre las salas y las listas de miembros en el mismo lugar, si desea poder iterar los grupos más adelante).
La principal diferencia entre los datos en tiempo real de Firebase y un entorno SQL es la consulta de datos. No existe una forma sencilla de decir “SELECCIONE USUARIOS DONDE X = Y”, debido a la naturaleza en tiempo real de los datos (están cambiando, fragmentando, reconciliando, etc. constantemente, lo que requiere un modelo interno más simple para mantener a los clientes sincronizados bajo control)
Un simple ejemplo probablemente lo pondrá en el estado mental correcto, así que aquí va:
/users/uid
/users/uid/email
/users/uid/messages
/users/uid/widgets
Ahora, dado que estamos en una estructura jerárquica, si quiero iterar las direcciones de correo electrónico de los usuarios, hago algo como esto:
// I could also use on('child_added') here to great success
// but this is simpler for an example
firebaseRef.child('users').once('value')
.then(userPathSnapshot =>
userPathSnapshot.forEach(
userSnap => console.log('email', userSnap.val().email)
);
)
.catch(e => console.error(e));
El problema con este enfoque es que acabo de obligar al cliente a descargar todos los archivos de los usuarios. messages y widgets también. No hay problema si ninguna de esas cosas se cuenta por miles. Pero un gran problema para 10k usuarios con más de 5k mensajes cada uno.
Así que ahora la estrategia óptima para una estructura jerárquica en tiempo real se vuelve más obvia:
/user_meta/uid/email
/messages/uid/...
/widgets/uid/...
Una herramienta adicional muy útil en este entorno son los índices. Al crear un índice de usuarios con ciertas attributespuedo simular rápidamente una consulta SQL simplemente iterando el índice:
/users_with_gmail_accounts/uid/email
Ahora, si quiero, digamos, recibir mensajes para los usuarios de Gmail, puedo hacer algo como esto:
var ref = firebase.database().ref('users_with_gmail_accounts');
ref.once('value').then(idx_snap =>
idx_snap.forEach(idx_entry =>
let msg = idx_entry.name() + ' has a new message!';
firebase.database().ref('messages').child(idx_entry.name())
.on(
'child_added',
ss => console.log(msg, ss.key);
);
);
)
.catch(e => console.error(e));
Ofrecí algunos detalles en otra publicación de SO sobre la desnormalización de datos, así que échales un vistazo también. Veo que Frank ya publicó el artículo de Anant, así que no lo repetiré aquí, pero también es una gran lectura.
Firebase es mucho no como una base de datos relacional. Si desea compararlo con algo, lo compararía con una base de datos jerárquica.
Anant escribió recientemente una excelente publicación en el blog de Firebase sobre la desnormalización de sus datos: https://www.firebase.com/blog/2013-04-12-denormalizing-is-normal.html
De hecho, sugeriría mantener la “ID” de cada aplicación como hijo de cada solicitante.
Su escenario parece uno a muchos en el mundo relacional, según su ejemplo, un solicitante tiene muchas aplicaciones. Si llegamos a firebase nosql way, se ve a continuación. Debería escalar sin ningún problema de rendimiento. Es por eso que necesitamos la desnormalización como se menciona a continuación.
applicants:
applicant1:
.
.
applications:
application1:true,
application3:true
,
applicant2:
.
.
applications:
application2:true,
application4:true
applications:
application1:
.
.
,
application2:
.
.
,
application3:
.
.
,
application4:
.
.
Sección de Reseñas y Valoraciones
Si sostienes algún titubeo y capacidad de limar nuestro post eres capaz de dejar un paráfrasis y con mucho gusto lo analizaremos.