firebase 데이터가 너무 많이 병합되고 있습니까?

답변을 드릴 수있는 게시물을 찾으려면 어떤 구조가 더 좋습니까?firebase 데이터가 너무 많이 병합되고 있습니까?

posts 
    908239409234 
     postText: "Whats up peeps?" 
     replies: 
      09283049830294: true 
      a9s0dif09iasd9: true 

replies 
    09283049830294 
     text: "Nm breh" 
     imageURL: nil 
    a9s0dif09iasd9 
     text: "Nm breh" 
     imageURL: nil

또는 2)

posts 
    908239409234 
     postText: "Whats up peeps?" 
     replies: 
     09283049830294 
      text: "Nm breh" 
      imageURL: nil 

     a9s0dif09iasd9 
      text: "Nm breh" 
       imageURL: nil

난 당신이 플래트 닝을 지원하기 위해 다른 곳에 저장 게시물에 대한 참조를 저장할 위치를 # 1과 같이 데이터베이스의 많은 예를 볼 수 있지만 I 할 수 있다면 옵션 2로 가지 않는 것이 어떤 이점도 보이지 않습니까?

사용자가 소식에 가입하면 게시물에 uid가 표시되며 자동 ID가있는 "답장"아래에 추가 할 수 있습니다.

TL; DR보다 평범한 방법이나 더 효율적인 정보이며 더 적은 정보로 검색해야하는 방법을 사용하는 것이 좋습니다. 옵션 2를 가지지 않는 이유가 있습니까?

출처

2016-07-30 J.Doe

나는 거절 할 것이다. 2. 그 이유는 no. 1 ID를 기반으로 응답 데이터를 가져 오기 위해 쿼리를 수행해야합니다. firebase을 사용하면 더 많이 쓰고 더 적게 읽을 수 있습니다.

출처

2016-07-30 06:43:37 Gil

나는 그것이 내가 생각했던 것이다. 나는 방금 # 1을 격려하는 많은 사람들의 예를 보았 기 때문에 나는 그것이 질의에 필요한 것을 과대 평가하는 것인지 몰랐다.하지만 네 # 2는 확실히 저에게 더 의미가 있습니다. 고마워요 –

나중에 어떤 점에서 답글을 참조할지 여부에 따라 달라집니다. 답글이 게시물에만 관련이 있고 더 이상 답장이 아닌 경우 답장을 가져올 필요가 없으므로 옵션 2가 최적입니다. 그러나 예를 들어 일부 사용자와 관련된 답장을 쿼리하는보다 복잡한 기능을 원할 경우 옵션 1로 각 답글에 대한 참조를 저장하는 것이 좋습니다. 이는 계속 성장하고있는 내 앱의 경험에서 비롯된 것입니다. 어떤 점에서는 너무 많은 자식, 손자 등이 있기 때문에 노드를 가져 오는 것이 너무 느리고 데이터베이스를 더 빨리 가져올 수 있도록 데이터베이스를 병합해야했습니다. 나는 당신의 애플 리케이션의 아키텍처에 대해 신중하게 생각하는 것이 좋습니다.

출처

2016-08-02 15:47:28 adbitx

옵션 1 대 2에 대한 주요 걱정거리는 데이터 사용량입니다. 응답 노드에 10,000 개의 응답이 저장되어있는 경우 특정 uid가 있으면 해당 목록에서 특정 하위 항목을 검색해야합니다. 잠재적 인 수천 개의 게시물/답글을 검색하지 않아도되도록 리팩터링했지만 큰 문제가 아니라면 최대한 평평하게 유지하는 것이 좋습니다. –

내 애플 리케이션과 내 솔루션 내 게시물에 대한 참조와 함께 더 빠르게 쿼리 할 필요가있는 응답에서 일부 데이터를 복사했지만 자세한 내용을 쿼리해야 할 경우 별도의 노드에서 데이터의 대부분을 유지. 나는 또한 데이터 가져 오기를 연기하거나 사용자가 포커스를 맞출 때 가져 오거나 뷰로 스크롤한다. 그것은 귀하의 애플 리케이션에 달렸어. 이것은 내 웹 앱에 대한 내 경험에 불과하며 앱에 적용되지 않을 수 있습니다. – adbitx

firebase 데이터가 너무 많이 병합되고 있습니까?

답변

관련 문제