data-structures - recuperar - guardar datos en firebase android
Estructura de datos y url de Firebase (1)
Soy nuevo en Firebase y en nosql, así que tengan paciencia conmigo para usar la referencia a sql. ¿Entonces mi pregunta es cómo estructurar los datos en Firebase?
En firebase, ¿eso significa cada "nueva base de fuego" = "nueva base de datos" o "tabla" en mysql?
Si en mi aplicación web en tiempo real, tengo usuarios y comentarios. En mysql, crearé una tabla de usuarios y una de comentarios y luego los vincularé.
¿Cómo estructura esto en Firebase?
Si tiene usuarios y comentarios, podría modelarlo fácilmente de esta manera:
ROOT
|
+-- vzhen
| |
| +-- Vzhen''s comment 1
| |
| +-- Vzhen''s comment 2
|
+-- Frank van Puffelen
|
+-- Frank''s comment 1
|
+-- Frank''s comment 2
Sin embargo, es más probable que exista una tercera entidad, como un artículo, y que los usuarios comenten artículos (de los demás).
Firebase no tiene el concepto de una clave externa, pero es fácil de imitar. Si lo hace, puede modelar la estructura de usuario / artículo / comentario de esta manera:
ROOT
|
+-- ARTICLES
| |
| +-- Text of article 1 (AID=1)
| |
| +-- Text of article 2 (AID=2)
|
+-- USERS
| |
| +-- vzhen (UID=1056201)
| |
| +-- Frank van Puffelen (UID=209103)
|
+-- COMMENTS
| |
| +-- Vzhen''s comment on Article 1 (CID=1)
| |
| +-- Frank''s response (CID=2)
| |
| +-- Frank''s comment on article 2 (AID=2,UID=209103)
|
+-- ARTICLE_USER_COMMENT
|
+-- (AID=1,UID=1056201,CID=1)
|
+-- (AID=1,UID=209103,CID=2)
|
+-- (AID=2,UID=209103,CID=3)
Este es un mapeo bastante directo de la forma en que lo modelaría en una base de datos relacional. El principal problema con este modelo es la cantidad de búsquedas que deberá hacer para obtener la información que necesita para una sola pantalla.
- Lea el artículo en sí (desde el nodo ARTICLES)
- Lea la información sobre los comentarios (del nodo ARTICULO_USER_COMMENT)
- Lea el contenido de los comentarios (del nodo COMMENTS)
Dependiendo de tus necesidades, incluso podrías necesitar leer el nodo USUARIOS.
Y tenga en cuenta que Firebase no tiene el concepto de una cláusula WHERE que le permite seleccionar solo los elementos de ARTICLE_USER_COMMENT que coinciden con un artículo específico o un usuario específico.
En la práctica, esta forma de mapeo de la estructura no es utilizable. Firebase es una estructura de datos jerárquica, por lo que debemos usar las habilidades únicas que nos da sobre el modelo relacional más tradicional. Por ejemplo: no necesitamos un nodo ARTICLE_USER_COMMENT, podemos simplemente mantener esta información directamente debajo de cada artículo, usuario y comentario.
Un pequeño fragmento de esto:
ROOT
|
+-- ARTICLES
| |
| +-- Text of article 1 (AID=1)
| . |
| . +-- (CID=1,UID=1056201)
| . |
| +-- (CID=2,UID=209103)
|
+-- USERS
| |
| +-- vzhen (UID=1056201)
| . |
| . +-- (AID=1,CID=1)
| .
|
+-- COMMENTS
|
+-- Vzhen''s comment on Article 1 (CID=1)
|
+-- Frank''s response (CID=2)
|
+-- Frank''s comment on article 2 (CID=3)
Puede ver aquí, que estamos difundiendo la información de ARTICLE_USER_COMMENT sobre el artículo y los nodos de usuario. Esto está desnormalizando los datos un poco. El resultado es que tendremos que actualizar varios nodos cuando un usuario agregue un comentario a un artículo. En el ejemplo anterior, deberíamos agregar el comentario en sí y luego los nodos al nodo de usuario y al nodo de artículo relevantes. La ventaja es que tenemos menos nodos para leer cuando necesitamos mostrar los datos.
Si llevas esta desnormalización al extremo, terminas con una estructura de datos como esta:
ROOT
|
+-- ARTICLES
| |
| +-- Text of article 1 (AID=1)
| | |
| | +-- Vzhen''s comment on Article 1 (UID=1056201)
| | |
| | +-- Frank''s response (UID=209103)
| |
| +-- Text of article 2 (AID=2)
| |
| +-- Frank''s comment on Article 2 (UID=209103)
|
+-- USERS
|
+-- vzhen (UID=1056201)
| |
| +-- Vzhen''s comment on Article 1 (AID=1)
|
+-- Frank van Puffelen (UID=209103)
|
+-- Frank''s response (AID=1)
|
+-- Frank''s comment on Article 2 (AID=2)
Puede ver que eliminamos los nodos COMMENTS y ARTICLE_USER_COMMENT en este último ejemplo. Toda la información sobre un artículo ahora se almacena directamente debajo del nodo del artículo, incluidos los comentarios sobre ese artículo (con un "enlace" al usuario que realizó el comentario). Y toda la información sobre un usuario ahora se almacena bajo el nodo de ese usuario, incluidos los comentarios que realizó el usuario (con un "enlace" al artículo del que trata el comentario).
Lo único que todavía es complicado con respecto a este modelo es el hecho de que Firebase no tiene una API para recorrer dichos "enlaces", por lo que tendrás que buscar tú mismo el usuario / artículo. Esto se vuelve mucho más fácil si usa el UID / AID (en este ejemplo) como el nombre del nodo que identifica al usuario / artículo.
Entonces eso lleva a nuestro modelo final:
ROOT
|
+-- ARTICLES
| |
| +-- AID_1
| | |
| | +-- Text of article 1
| | |
| | +-- COMMENTS
| | |
| | +-- Vzhen''s comment on Article 1 (UID=1056201)
| | |
| | +-- Frank''s response (UID=209103)
| |
| +-- AID_2
| |
| +-- Text of article 2
| |
| +-- COMMENTS
| |
| +-- Frank''s comment on Article 2 (UID=209103)
|
+-- USERS
|
+-- UID_1056201
| |
| +-- vzhen
| |
| +-- COMMENTS
| |
| +-- Vzhen''s comment on Article 1 (AID=1)
|
+-- UID_209103
|
+-- Frank van Puffelen
|
+-- COMMENTS
|
+-- Frank''s response (AID=1)
|
+-- Frank''s comment on Article 2 (AID=2)
Espero que esto ayude a entender el modelado de datos jerárquico y las compensaciones involucradas.