En esta guía, se presentan algunos de los conceptos clave sobre la arquitectura de datos y las prácticas recomendadas para la estructuración de los datos JSON de tu Firebase Realtime Database.
La creación de una base de datos estructurada de forma adecuada requiere bastante previsión. La parte más importante es planificar cómo se guardarán y recuperarán los datos para que el proceso sea lo más simple posible.
Cómo se estructuran los datos: en un árbol JSON
Todos los datos de Firebase Realtime Database se almacenan como objetos JSON. La base de datos puede conceptualizarse como un árbol JSON alojado en la nube. A diferencia de una base de datos de SQL, no hay tablas ni registros. Cuando le agregas datos al árbol JSON, estos se convierten en un nodo de la estructura JSON existente con una clave asociada. Puedes proporcionar tus propias claves,
como IDs de usuario o nombres semánticos, o también puedes obtenerlas con
la solicitud POST.
Si creas tus propias claves, estas deben usar codificación UTF-8, pueden tener un máximo de 768 bytes y no pueden contener los caracteres ., $, #, [, ], / ni los caracteres de control ASCII del 0 al 31 ni el 127. Tampoco puedes usar los caracteres de control ASCII en los propios valores.
Por ejemplo, imagina una aplicación de chat que permite que los usuarios almacenen un perfil básico y una lista de contactos. Un perfil de usuario común se ubica en una ruta de acceso, como /users/$uid. El usuario alovelace podría tener una entrada en la base de datos similar a la siguiente:
{ "users": { "alovelace": { "name": "Ada Lovelace", "contacts": { "ghopper": true }, }, "ghopper": { "..." }, "eclarke": { "..." } } }
Aunque la base de datos usa un árbol JSON, los datos almacenados en ella pueden representarse como determinados tipos nativos que corresponden a los tipos de JSON disponibles para que puedas escribir un código más fácil de mantener.
Prácticas recomendadas para la estructura de datos
Evita la anidación de datos
Debido a que Firebase Realtime Database permite anidar datos hasta 32 niveles de profundidad, es posible que te resulte tentador pensar que esta debe ser la estructura predeterminada. Sin embargo, cuando obtienes datos de una ubicación de la base de datos, también se recuperan todos los nodos secundarios. Además, cuando le otorgas a alguien acceso de lectura o escritura en un nodo de la base de datos, también le otorgas acceso a todos los datos que se encuentran en ese nodo. Por lo tanto, en la práctica, lo ideal es que la estructura de los datos sea lo más simple posible.
Para entender mejor por qué no son una buena opción los datos anidados, considera la siguiente estructura de anidación en varios niveles:
{ // This is a poorly nested data architecture, because iterating the children // of the "chats" node to get a list of conversation titles requires // potentially downloading hundreds of megabytes of messages "chats": { "one": { "title": "Historical Tech Pioneers", "messages": { "m1": { "sender": "ghopper", "message": "Relay malfunction found. Cause: moth." }, "m2": { ... }, // a very long list of messages } }, "two": { "..." } } }
Con este diseño anidado, se vuelve problemática la iteración de datos. Por ejemplo, para obtener una lista de los títulos de conversaciones de chat, debe descargarse al cliente todo el árbol chats, incluidos todos los miembros y los mensajes.
Compacta las estructuras de datos
Por el contrario, si los datos se dividen en rutas de acceso independientes, que también se conocen como no normalizadas, se pueden descargar de manera eficaz en llamadas separadas, según sea necesario. Considera esta estructura compacta:
{ // Chats contains only meta info about each conversation // stored under the chats's unique ID "chats": { "one": { "title": "Historical Tech Pioneers", "lastMessage": "ghopper: Relay malfunction found. Cause: moth.", "timestamp": 1459361875666 }, "two": { "..." }, "three": { "..." } }, // Conversation members are easily accessible // and stored by chat conversation ID "members": { // we'll talk about indices like this below "one": { "ghopper": true, "alovelace": true, "eclarke": true }, "two": { "..." }, "three": { "..." } }, // Messages are separate from data we may want to iterate quickly // but still easily paginated and queried, and organized by chat // conversation ID "messages": { "one": { "m1": { "name": "eclarke", "message": "The relay seems to be malfunctioning.", "timestamp": 1459361875337 }, "m2": { "..." }, "m3": { "..." } }, "two": { "..." }, "three": { "..." } } }
Ahora, es posible iterar la lista de salas, para lo cual solo se descargan algunos bytes de cada conversación. Esto permite obtener rápidamente los metadatos necesarios para generar una lista o mostrar las salas en la IU. Los mensajes se pueden obtener por separado y mostrarse cuando llegan, lo que permite que la IU sea ágil y rápida.
Crea datos escalables
Cuando se crean apps, por lo general es mejor descargar un subconjunto de una lista. Esto resulta particularmente común si la lista contiene miles de registros. Cuando esta relación es estática y unidireccional, simplemente se pueden anidar los objetos secundarios bajo los primarios.
A veces, esta relación es más dinámica o tal vez se necesite desnormalizar los datos. En muchas ocasiones, los datos pueden desnormalizarse mediante una consulta para recuperar un subconjunto de estos, tal como se explica en Recupera datos.
Pero incluso esto puede no ser suficiente. Por ejemplo, considera una relación bidireccional entre usuarios y grupos. Los usuarios pueden pertenecer a un grupo, y los grupos son una lista de usuarios. Sin embargo, cuando llega el momento de decidir a qué grupo pertenece un usuario, la situación se complica.
Se necesita un modo elegante de obtener una lista de los grupos a los que pertenece un usuario y de conseguir solo los datos correspondientes a esos grupos. Para ello, puede ser útil contar con un índice de grupos:
// An index to track Ada's memberships { "users": { "alovelace": { "name": "Ada Lovelace", // Index Ada's groups in her profile "groups": { // the value here doesn't matter, just that the key exists "techpioneers": true, "womentechmakers": true } }, // ... }, "groups": { "techpioneers": { "name": "Historical Tech Pioneers", "members": { "alovelace": true, "ghopper": true, "eclarke": true } }, // ... } }
Posiblemente hayas notado que esto duplica algunos datos, ya que la relación se almacena tanto en el registro de Ada como en el grupo. Ahora, alovelace está indexada en un grupo, y techpioneers está incluido en el perfil de Ada. Por lo tanto, para borrar a Ada del grupo, es necesario actualizar la información en dos lugares.
Es una redundancia necesaria para una relación bidireccional. Esto permite obtener la información de los grupos a los que pertenece Ada con rapidez y eficacia, incluso si la lista de usuarios o grupos contiene millones de elementos o si hay reglas de seguridad de Realtime Database que impiden el acceso a algunos de los registros.
Este enfoque, en el que se invierten los datos mediante la enumeración de los ID como claves y la asignación del valor “true”, hace que buscar una clave sea tan sencillo como leer /users/$uid/groups/$group_id y comprobar si el valor es null. El índice es más rápido y mucho más eficiente que consultar o analizar los datos.