와이어 프레임

miro.com

• 정리한 기능을 기반으로 와이어 프레임 구성 시도

• 앱의 핵심 기능, UX를 고려하여 와이어 프레임을 구성하는 것은 난이도가 높다. 하지만 해야한다.

• 기획, UX 경험이 부족하여 와이어 프레임 구성에 시행착오가 꽤 많았다.

• 그럼에도 불구하고 팀원들의 의견과 핵심 기능을 고려하여 구성했다.

• 애자일 방식으로 개발하며 세세한 부분들이 꽤 많이 바뀔 것 같다.

  

DB 설계 단계에서 예상하는 문제

데이터 양이 많아졌을 때(100만명의 사용자, 각 100벌의 옷 = 1억), 사용자 id로 select 하면 성능이 빠르지 않을 것으로 예상한다.

방안

• Clothes에 모든 사용자의 모든 옷을 넣는다. → 일단 이 방식으로 결정
  • 사용자가 추가될 때마다 테이블을 새로 만드는 것은 상식적으로 이상하다.
  • CUD 작업은 많이 일어나지 않을 것으로 예상한다.
• 사용자가 추가될 때마다 각 사용자의 옷을 담는 table을 생성한다.

DB 선택 RDBMS vs nosql

SQL의 장점

• 명확하게 정의 된 스키마, 데이터 무결성 보장
• 관계는 각 데이터를 중복없이 한번만 저장(Normalization)

NoSQL의 장점

• 스키마가 없기때문에, 훨씬 유연
• 즉, 언제든지 저장된 데이터를 조정하고 새로운 "필드"를 추가 가능
• 데이터는 애플리케이션이 필요로 하는 형식으로 저장, 읽기 속도 향상
• 수직 및 수평 확장이 가능하므로 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기 / 쓰기 요청 처리 가능

SQL의 단점

• 상대적으로 덜 유연
• 데이터 스키마는 사전 계획 필수(나중에 수정하기가 번거롭거나 불가능 할 수 도 있다.)
• 관계를 맺고 있기 때문에, JOIN문이 많은 매우 복잡한 쿼리가 만들어 질 가능성
• 수평적 확장이 어렵고, 대체로 수직적 확장만 가능. 즉 어떤 시점에서 (처리 할 수 있는 처리량과 관련하여) 성장 한계에 직면

NoSQL의 단점

• 유연성 때문에, 데이터 구조 결정을 미룸
• 데이터 중복은 여러 컬렉션과 문서가 (SQL처럼 하나의 테이블에 하나의 레코드가 아니라) 여러 개의 레코드가 변경된 경우 업데이트 진행
• 데이터가 여러 컬렉션에 중복되어 있기 때문에, 수정(update)를 해야 하는 경우 모든 컬렉션에서 업데이트(SQL은 중복된 데이터가 없기 때문에 한번만 수행)

SQL이 적합한 상황

• 관계를 맺고 있는 데이터가 자주 변경(수정)되는 애플리케이션일 경우 (NoSQL에서라면 여러 컬렉션을 모두 수정해야 한다.)
• 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우

NoSQL이 적합한 상황

• 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우
• 읽기(read)처리를 자주하지만, 데이터를 자주 변경(update)하지 않는 경우 (즉, 한번의 변경으로 수십 개의 문서를 업데이트 할 필요가 없는 경우)
• 데이터베이스를 수평으로 확장해야 하는 경우 ( 즉, 막대한 양의 데이터를 다뤄야 하는 경우)