Firebase 데이터 구조 및 URL
저는 Firebase에 새로 왔고 nosql은 sql에 대한 참조를 사용하는 것에 동의합니다.그래서 제 질문은 어떻게 파이어베이스에서 데이터를 구성하느냐 하는 것입니다.
Firebase에서 mysql의 모든 "새로운 Firebase" = "새로운 데이터베이스" 또는 "테이블"을 의미합니까?
제 실시간 웹 앱에는 사용자와 댓글이 있습니다.mysql에서, 나는 사용자와 주석 표를 만든 후 그들을 연결할 것입니다.
소방대에서 이걸 어떻게 구성하죠?
사용자와 의견이 있는 경우 다음과 같이 쉽게 모델링할 수 있습니다.
ROOT
|
+-- vzhen
| |
| +-- Vzhen's comment 1
| |
| +-- Vzhen's comment 2
|
+-- Frank van Puffelen
|
+-- Frank's comment 1
|
+-- Frank's comment 2
그러나 기사와 같은 제3의 엔티티가 있고 사용자가 (서로의) 기사에 댓글을 달 가능성이 더 높습니다.
파이어베이스는 외부 키의 개념이 없지만, 흉내내기는 쉽습니다.이렇게 하면 다음과 같은 사용자/기사/주석 구조를 모델링할 수 있습니다.
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)
이것은 관계형 데이터베이스에서 이를 모델링하는 방법을 직접 매핑한 것입니다.이 모델의 주요 문제는 단일 화면에 필요한 정보를 얻기 위해 수행해야 하는 조회 수입니다.
- 기사 노드에서 기사 자체 읽기
- 주석에 대한 정보를 읽습니다(ARTINE_USER_COMMNT 노드에서).
- 의견 노드에서 의견의 내용을 읽습니다.
필요에 따라 USERS 노드도 읽어야 할 수 있습니다.
또한 Firebase에는 특정 아티클 또는 특정 사용자와 일치하는 요소만 선택할 수 있는 WHERE 절 개념이 없습니다.
실제로 이러한 구조 매핑 방식은 사용할 수 없습니다.Firebase는 계층적 데이터 구조이므로 더 전통적인 관계형 모델에 비해 고유한 기능을 사용해야 합니다.예를 들어, ARTINE_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)
여기 보시면 기사와 사용자 노드를 통해 ARTINE_USER_COMMENT의 정보를 퍼뜨리고 있습니다.이것은 데이터를 약간 비 정규화하는 것입니다.따라서 사용자가 기사에 주석을 추가할 때 여러 노드를 업데이트해야 합니다.위의 예에서는 주석 자체를 추가한 다음 노드를 관련 사용자 노드 및 문서 노드에 추가해야 합니다.장점은 데이터를 표시해야 할 때 읽을 노드가 적다는 것입니다.
이러한 비정규화를 가장 극단적으로 적용하면 다음과 같은 데이터 구조가 됩니다.
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)
이 마지막 예제에서는 CONMESS와 ARTINE_USER_COMMENT 노드를 제거한 것을 볼 수 있습니다.이제 해당 기사에 대한 주석(주석을 작성한 사용자에 대한 "링크" 포함)을 포함하여 기사 노드 바로 아래에 모든 정보가 저장됩니다.이제 사용자에 대한 모든 정보가 해당 사용자의 노드 아래에 저장됩니다. 여기에는 사용자가 작성한 주석(주석에 대한 기사에 대한 "링크" 포함)이 포함됩니다.
이 모델에서 여전히 까다로운 점은 Firebase가 이러한 "링크"를 통과할 수 있는 API를 가지고 있지 않기 때문에 사용자/기사를 직접 찾아봐야 한다는 것입니다.UID/AID(이 예에서는 UID/AID)를 사용자/기사를 식별하는 노드의 이름으로 사용하면 훨씬 쉬워집니다.
이것이 최종 모델로 이어집니다.
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)
저는 이것이 계층적 데이터 모델링과 관련된 트레이드오프를 이해하는 데 도움이 되기를 바랍니다.
언급URL : https://stackoverflow.com/questions/16638660/firebase-data-structure-and-url
'programing' 카테고리의 다른 글
| SQL Server가 없는 경우 사용하시겠습니까? (0) | 2023.07.11 |
|---|---|
| Oracle Date TO_CHAR('Month DD, YYY')에 추가 공간이 있습니다. (0) | 2023.07.11 |
| HttpOnly Spring 부팅 끄기 (0) | 2023.07.11 |
| 임의의 날짜로 행을 업데이트하는 방법 (0) | 2023.07.11 |
| 케스트렐과 카타나의 구별 (0) | 2023.07.11 |