안녕하세요. 개남님. 구글 파이어스토어 DB를 사용합니다. 필드 구성에 따른 데이터 용량, 속도에 대한 질문드립니다. - 1번 구성: 키 필드, 배열 필드로 구성 '2QB6p5Q1foupGg87', ['슈가', '제이홉', '정국'] - 2번 구성: 키 필드, 이름으로 구성 '2QB6p5Q1foupGg87', '슈가' '2QB6p5Q1foupGg87', '제이홉' '2QB6p5Q1foupGg87', '정국' 1번은 한개의 row에 모두 저장, 2번은 이름마다 각각 row를 생성한다고 가정하면 이 둘의 데이터 용량, 속도의 차이가 궁금합니다. 얼핏 보기엔 2번용량이 1번용량의 거의 3배가량 될 거 같고 응답속도도 많이 떨어질것 같은데 어떤지요? 감사합니다.
안녕하세요. 데이터에 관해 질문을 주셨네요 ㅎㅎ 우선 제가 DBA처럼 데이터를 효율적으로 관리하는 개발자가 아니라서 1번구성/2번구성중 뭐가 더 좋다에대해서 정확한 근거를 를 바탕으로 설명드릴수는 없지만 제 개인적인 의견(정답은 아니라는 점 참고 부탁드립니다)으로는 2번의 설계방식의 경우 SQL에서 사용되는 구조를 띄는 것 같습니다. 파이어베이스의 경우 no-sql 의 데이터기때문에 좀 더 빠르게 처리 할 수 있는 구조로 설계한는 게 좋지 않을까? 싶네요 데이터의 응답속도의 경우는 3개의 데이터가 저장되있을때는 둘다 체감하지 못할 정도의 속도로 비슷할 테지만 저장되어있는 값이 3개가 아닌 10만개 100만개가 저장되어야 한다면 1번의 경우는 SQB6p5 키로 ['슈가'.........'100만번째 정국'] 이렇게 한row 로 처리가 되지만 2번의 경우는 100만건의 데이터가 저장되게 됩니다. 조회시 어떤 것이 더 빠르게 처리 될지 느낌이 오실 것이라 생각합니다. 또한 키값이 불변한 것으로 설계될 수도 있지만 키값이 바뀌는 상황도 고려해야 하는 데이터 구조라면 1번의 경우 데이터 update 가 1번이면 처리 되지만 2번의 경우 100만건의 update 가 이루어 질 것입니다. 비용적인 측면으로 봤을때에도 1번 구조가 좋다라고 생각됩니다. 하지만 파이어베이스의 경우 하나의 row 제한된 용량만 저장이 가능한 것으로 알고 있습니다. 제한된 용량 이상이 한 row 에 저장되지 않도록 설계도 신경써야 할 것입니다.
오~~ 그렇군요! MVC까지는 그래도 들어보고 로직 짜면서 적용한다고 했었습니다. 하지만 MVVM 이란건 개남님 유튜브 보면서 처음 봤고 아무것도 몰랐었죠. 근데 이제 알겠네요. MVVM은 MVC의 확장 개념이네요. MVC 의 C를 VM으로 쪼개 놓은거군요. 정말 감사합니다. 근데 그냥 언뜻 생각하기에는 MVVM으로 처음부터 짠다면 뷰 모델을 하나 더 만들어야하기에 뭔가 코딩을 더 많이 해야하는 느낌이긴 하겠네요. 물론 이렇게 짜놔야 유지보수 엄청난 이점이 있다는건 알겠지만요.
provider mvvm 설명하는 ui에서 stateful을 사용한 이유는 없습니다. stateless 위젯을 사용해도 상관이 없습니다. 영상을 찍을때 stateful로만들어줬는데 ;; stateful이던 stateless던 상관 없다는것만 알아주시면 될것 같습니다 ^^:;
좋은 질문인것 같습니다 저도 다시한번 PRICE 부분 문서를 읽어봤는데요 문서 링크는 다음과 같습니다. cloud.google.com/firestore/pricing?authuser=0 1000건이 있다고 해서 1000건에 해당하는 비용이 부과 되는것 같지는 않습니다. 조회된 결과에 대해서100 건에 대해서만 부과되는것으로 보시면 될것 같습니다. 단, 컬렉션에 보안 규칙이 설정되어있을경우 보안 규직의 따라 추가 건수가 발생할 수 있습니다. 아무래도 편하게 개발하는것은 좋긴하지만,, 비용에대해서는 신중하게 검토하셔서 이용하시는 것이 좋을 것 같습니다 ~!
getx로 개발을 하게 되면 대게 mvvm의 형태로 개발하게 됩니다. 또한 영상 초반에도 언급을 하였지만. 플러터 프레임워크의 경우 mvc나 mvvm을 차용해서 설계되지 않았습니다. 자유롭게 개발을 할 수 있도록 설계가 되어있는데 개발자들이 원하는 패턴을 적용해서 개발이 가능합니다. getx로 mvc패턴을 적용해서 개발을 원하시면 그렇게 개발을 하시면 되겠습니다. 개발 방법론 적으로 봤을때 뭐가 최고고 정답이다는 없는 것 같습니다. 상황이나 함께 일하는 팀원들의 의견과 조율을 통해 최적의 개발방식을 만들어가는 것 같습니다.