Estructura de datos y URL de Firebase
Soy nuevo en Firebase y nosql, así que tengan paciencia para usar referencias 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 de comentarios y luego los vincularé.
¿Cómo estructuro esto en firebase?
Si tiene usuarios y comentarios, puede modelarlo fácilmente así:
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 los artículos (de los demás).
Firebase no tiene el concepto de clave externa, pero es fácil imitarlo. Si haces eso, puedes modelar la estructura 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 modelarías esto en una base de datos relacional. El principal problema de este modelo es la cantidad de búsquedas que deberá realizar para obtener la información que necesita para una sola pantalla.
- Lea el artículo en sí (desde el nodo ARTÍCULOS)
- Leer la información sobre los comentarios (del nodo ARTICLE_USER_COMMENT)
- Leer el contenido de los comentarios (desde el nodo COMENTARIOS)
Dependiendo de sus necesidades, es posible que incluso necesite leer también el nodo USUARIOS.
Y tenga en cuenta que Firebase no tiene el concepto de una cláusula WHERE que le permita 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 mapear la estructura no es utilizable. Firebase es una estructura de datos jerárquica, por lo que debemos utilizar las capacidades únicas que nos brinda sobre el modelo relacional más tradicional. Por ejemplo: no necesitamos un nodo ARTICLE_USER_COMMENT, podemos 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 en los nodos de artículo y usuario. Esto está desnormalizando un poco los datos. El resultado es que necesitaremos actualizar varios nodos cuando un usuario agregue un comentario a un artículo. En el ejemplo anterior, tendríamos que 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, terminarás 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 nos deshicimos de 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 hizo el comentario). Y toda la información sobre un usuario ahora se almacena en el nodo de ese usuario, incluidos los comentarios que hizo el usuario (con un "enlace" al artículo sobre el que trata el comentario).
Lo único que sigue siendo complicado acerca de este modelo es el hecho de que Firebase no tiene una API para atravesar dichos "enlaces", por lo que tendrás que buscar el usuario/artículo tú mismo. 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.
Eso nos 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 comprender el modelado de datos jerárquico y las compensaciones involucradas.
