Firebase 데이터베이스 설계 권장 사항

조직 구성원 및 지불을 처리하는 응용 프로그램을 작성 중입니다. 나는 다음과 같은 요소를 가지고 :Firebase 데이터베이스 설계 권장 사항

Organization---+ 
       | 
       +---Members-----+ 
       |    | 
       |    +---Children 
       +---Accounts 
       | 
       +---Payments

가> 10 만 조직 당 지불,하지만 몇 회원들과 계정이있을 수 있습니다. 회원이 로그인하면 그는 자신의 지불 만 볼 수 있습니다. 관리자가 로그인하면 모든 데이터에 액세스 할 수 있어야합니다.

질문은 다음과 같습니다

내가 조직의 계층 구조를 유지해야하거나 내가 각 엔티티를 평평해야합니까? 나는 구조 계층을 유지하고 싶은 경우
, 그것은 가능한 부분적인 하위 컬렉션 (모든 회원들과 모든 지불)

감사와 조직을 얻는 것입니다.

출처

2017-02-26 Ronen

미래의 질문을 위해 근사값/모델이 아닌 실제 JSON을 공유하십시오. 이제 당신은 두 가지 답이 맞을지 모릅니다. 우리는 당신을 돕는 대신 다른 의미가 무엇인지 알아 내려고 노력하고 있습니다. –

구조는 평평하고 가능한 한 비정규 화 된 상태로 유지해야합니다. 상위 노드를 쿼리하면 모든 하위 노드와 데이터가로드됩니다.

예, 사용 가능한 SDK를 사용하여 계속 쿼리/필터를 사용할 수 있습니다.

출처

2017-02-26 20:48:18 alltej

나는 즉시 반대하지는 않지만 왜 데이터를 납부액 목록으로 보관해야한다고 생각하는지 설명 할 수 있습니까? –

다음은 firebase nosql 데이터베이스 설계에 대한 링크입니다. https://firebase.google.com/docs/database/web/structure-data – alltej

해당 문서를 잘 알고 있습니다. 그러나 나는 당신이 여기에 적용되는 부분이 무엇인지 이해하지 못합니다. 하나의 계층 구조에서 서로 다른 데이터 유형을 결합하는 것은 거의 잘못된 생각입니다. 그러나 내가 볼 수있는 한 여기에는 적용되지 않습니다. 컬렉션을 중첩하는 것은 Firebase 실시간 데이터베이스에서 상당히 일반적이며 가장 좋은 해결책입니다. –

Firebase의 실시간 데이터베이스에서 항상 염두에 두어야 할 것은 검색하는 데이터의 양과 데이터베이스를 만드는 데이터의 양입니다.

데이터베이스에 현재 사용자에 대해 < 지불 10 만 건을 표시하도록 고려하면 많은 자원을 낭비하게됩니다. 여기에 대한 자세한 내용은 Firebase Scalability Limit 및 Firebase Performance: How many children per node?입니다.

각 사용자에 대한 지불을 개별적으로 모델링하면 서버가 고려해야하는 데이터의 양이 크게 줄어 듭니다. 이것은 물론 선형 적이 지 않지만 확장 성을 향상시킵니다.

관리자 사용자가 모든 데이터를 볼 필요가 있다면 먼저 해당 사용자를 선택하도록 권장합니다. 그런 다음 일반 사용자와 동일한 액세스 패턴을 따릅니다.

출처

2017-02-26 22:28:04

Firebase 데이터베이스 설계 권장 사항

답변

관련 문제