Firebase 데이터 구조 및 URL

Firebase 데이터 구조 및 URL

---

나는 Firebase와 nosql을 처음 사용하므로 sql에 대한 참조를 사용하십시오. 그래서 내 질문은 firebase에서 데이터를 구조화하는 방법입니다.

firebase에서는 mysql의 모든 "new firebase"= "new Database"또는 "table"을 의미합니까?

내 실시간 웹 앱에 사용자와 댓글이 있습니다. mysql에서 사용자와 주석 테이블을 만든 다음 서로 연결합니다.

Firebase에서 어떻게 구성합니까?

---

사용자와 댓글이있는 경우 다음과 같이 쉽게 모델링 할 수 있습니다.

ROOT
 |
 +-- vzhen
 |     |
 |     +-- Vzhen's comment 1
 |     |
 |     +-- Vzhen's comment 2
 |
 +-- Frank van Puffelen
       |
       +-- Frank's comment 1
       |
       +-- Frank's comment 2

그러나 기사와 같은 세 번째 엔티티가 있고 사용자가 (서로의) 기사에 댓글을 달 가능성이 더 높습니다.

Firebase에는 외래 키 개념이 없지만 모방하기 쉽습니다. 그렇게하면 다음과 같이 사용자 / 기사 / 댓글 구조를 모델링 할 수 있습니다.

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)

이것은 관계형 데이터베이스에서 이것을 모델링하는 방식을 매우 직접적으로 매핑 한 것입니다. 이 모델의 주된 문제는 단일 화면에 필요한 정보를 얻기 위해 수행해야하는 조회 횟수입니다.

1. 기사 자체 읽기 (ARTICLES 노드에서)
2. 주석에 대한 정보를 읽습니다 (ARTICLE_USER_COMMENT 노드에서).
3. 주석 내용 읽기 (COMMENTS 노드에서)

필요에 따라 USERS 노드도 읽어야 할 수도 있습니다.

Firebase에는 특정 기사 또는 특정 사용자와 일치하는 ARTICLE_USER_COMMENT의 요소 만 선택할 수있는 WHERE 절 개념이 없습니다.

실제로이 구조 매핑 방법은 사용할 수 없습니다. Firebase는 계층 적 데이터 구조이므로보다 전통적인 관계형 모델에 대해 제공하는 고유 한 기능을 사용해야합니다. 예를 들어 ARTICLE_USER_COMMENT 노드가 필요하지 않습니다.이 정보를 각 기사, 사용자 및 댓글 자체 아래에 직접 보관할 수 있습니다.

이것의 작은 스 니펫 :

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)

여기에서 ARTICLE_USER_COMMENT의 정보가 아티클과 사용자 노드에 퍼지고 있음을 알 수 있습니다. 이것은 데이터를 약간 비정규 화합니다. 그 결과 사용자가 기사에 댓글을 추가 할 때 여러 노드를 업데이트해야합니다. 위의 예에서 우리는 주석 자체를 추가 한 다음 관련 사용자 노드 및 기사 노드에 노드를 추가해야합니다. 장점은 데이터를 표시해야 할 때 읽을 노드가 적다는 것입니다.

If you take this denormalization to its most extreme, you end up with a data structure like this:

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)

You can see that we got rid of the COMMENTS and ARTICLE_USER_COMMENT nodes in this last example. All the information about an article is now stored directly under the article node itself, including the comments on that article (with a "link" to the user who made the comment). And all the information about a user is now stored under that user's node, including the comments that user made (with a "link" to the article that the comment is about).

The only thing that is still tricky about this model is the fact that Firebase doesn't have an API to traverse such "links", so you will have to look up the user/article up yourself. This becomes a lot easier if you use the UID/AID (in this example) as the name of the node that identifies the user/article.

So that leads to our final model:

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)

I hope this helps in understanding hierarchical data-modelling and the trade-offs involved.

ReferenceURL : https://stackoverflow.com/questions/16638660/firebase-data-structure-and-url