2. DB - ERD 설계

[sypatrick]

test

test

[sypatrick]

[sypatrick]

1. 호텔 이름 번역

• 처음 회원가입할 때 국가를 필수로 입력하게 한 후, 해당 유저가 로그인시 체크해서 호텔 조회시 번역 API를 사용한다.
  • (백엔드 -> 영어로만 저장, 프론트엔드 -> 언어패키지나 번역 API 사용) 혹은 영어로만 저장해두고 백엔드에서 조회할 때 번역 api(google 혹은 aws translate api)사용해서 전달

2. 이미지 저장 방법

• json 형식으로 하나의 컬럼에 url을 저장할 수 있는 방법도 있으나 저장 한계가 있다. 그러므로 별도의 테이블(image_archive)을 구성해서 이미지 저장

3. 숙소 설명의 이모티콘

• 해당 테이블의 문자 인코딩을 UTF-8mb4로 변경하면 이모티콘 포함 모든 유니코드 문자를 사용할 수 있다.

4. 면적 단위

• 국제 표준인 m2 로 기본 저장을 하고 필요에 따라 한국에서 주로 사용하는 평, 미국의 평방 피트, 영국이나 유럽의 평방 야드 등을 추가로 변환하는 작업을 하면 좋을 것 같다.

5. 타임존 관리

• timestamp 사용시 서버 타임존 설정에 따라 데이터 조회시 자동으로 변환되므로, 다양한 타임존을 사용해야하는 글로벌 시스템에서는 이로 인해 복잡함이 발생할 수 있기 때문에 datetime을 사용한다.

  • 관리방안 1 ) 유저가 가입할 때 국적을 필수로 가입을 하게 되면 그 국적에 맞는 타임존을 datetime 저장할때 timezone 컬럼에 같이 저장한다. 2 ) 서버 타임존을 UTC로 맞춰서 애플리케이션단에서 시간 변환 로직 구현.

6. 회원 등급

• 필드 타입을 enum 타입으로 설정할 경우 데이터의 무결성 보장, enum은 내부적으로 정수 값으로 저장되어 저장공간 절약이라는 이점, 문자열이 아니라 정수로 저장되기 때문에 쿼리 성능 향상을 기대해 볼 수 있다.

• 단점으로는 등록 삭제, 수정의 번거로움. 그때마다 데이터베이스를 변경해야하는데에 있어 관리의 복잡성이 있을 수 있다.

• 결론 : grade 컬럼이 자주 변경되지 않고, 회원 등급의 특징을 생각해보면 비교적 그 수가 적고 고정되어 있으며 자주 변경될 여지가 적으므로 충분히 사용될만 하다고 생각해서 enum으로 변경.

7. 리뷰에서 텍스트 중간에 사진이 포함되었을 때 처리 방법

1) 생성된 html을 그대로 DB에 저장 (DB 저장공간 문제) 2) 이미지를 이미지 추가 API에서 추가할 때 서버에 저장하고 즉시 url을 받는 방법 2-1) 백엔드에서는 이미지 url만 관리, 나머지는 프론트엔드에서 위치 크기 조절 2-2) 태그 포함된 글 전체를 텍스트로 저장, 마치 깃허브에서 issue에 글쓸 때 priview 보기전에 Write 탭에서 '![이름](url)'로 작성하는 것과 같이..

8. 현 DB 모델링에서 admin이 댓글을 남길 수 있는 방법

• 애플리케이션 단에서 로직을 추가한다.

  • 예를 들어 admin 댓글인 경우 user인지 admin인지 확인한 후 user_id를 null로 처리하거나 별도의 플래그 사용.

  위 방법은 유연하게 애플리케이션 단에서 관리가 가능하지만, 실수로 인해 데이터가 일관되게 관리 되지 않을 수 있다.

• DB 구조를 변경한다면, reply 테이블에 admin_id 외래키 추가

[f-lab-robert]

UTF-8mb4

1. UTF8 mb4 는 무엇이며 그에 준하는 대체제 들은 무엇이 있을까요

2. 타임존 관리

   • 가장 핵십은 항상 UTC 로 DB 에 저장하고, 백엔드 혹은 프론트엔드에서 요청을 한 사용자의 위치를 바탕 ( 어떻게 백엔드와 프론트엔드에서 현재 요청한 사용자의 위치를 알 수 있을까요 ) 으로 현지 시간으로 변환해주면 좋지 않을까 생각합니다.

3. 리뷰에서 텍스트 중간에 사진이 포함되었을 때 처리 방법

4. 생성된 html을 그대로 DB에 저장 (DB 저장공간 문제) -> 잘 이해가 되지 않습니다. 더 구체적인 설명이 필요할 것 같습니다.

5. 2-1) 의 옵션을 잘 생각해보시면 프론트엔드에서는 어떻게 위치와 이미지의 크기를 알 수 있을까요. 불가능해보입니다.

6. 2-2) 의 옵션을 구현 가능해보입니다. 다만, 프론트 엔드 관점에서 어떤 부분을 신경써야할지 생각해보면 좋을 것 같습니다.

[sypatrick]

UTF-8mb4

• UTF-8mb4는 Mysql데이터 베이스에서 문자열을 저장하기 위해 사용하는 문자 집합이다. Mysql에서 UTF-8의 문자 집합은 1~3바이트까지의 문자만 지원하는 반면, UTF-8mb4(multibyte4)는 최대 4바이트까지 문자를 지원하므로 이모티콘이나 기타 특수 문자를 포함한 모든 유니코드 문자를 저장할 수 있다.
• UTF-8 이더라도 이모티콘을 아예 못쓰는 것은 아니다. 하트(♥) 와 같은 이모티콘은 3바이트 이내이므로 저장이 가능하다.

대체제

UTF-16

• UTF-16은 대부분의 이모티콘을 저장할 수 있다. MySQL에서는 'utf16' 또는 'utf16le' 캐릭터셋으로 사용 가능하다.

UTF-32

• 모든 유니코드 문자(이모티콘 포함)를 저장할 수 있다. MySQL에서는 'utf32' 캐릭터셋으로 사용 가능하다.

하지만 UTF-16, 32는 저장 공간이 많이 필요하며, UTF-8 mb4에 비해 저장 공간 효율성이 낮아 UTF-8 mb4를 사용하는 것이 낫다.

사용자의 위치 확인

백엔드

IP기반 위치확인 API 및 라이브러리를 활용하면 사용자의 IP주소를 기반으로 대략적인 위치를 파악 할 수 있다.

• MaxMind GeoIP2

  특징: IP 주소를 기반으로 국가, 도시, 위도/경도, ISP 등의 정보 제공 장점: 대규모 데이터베이스, 정기적인 업데이트 사용: 다양한 프로그래밍 언어에서 사용 가능 (Python, PHP, Java 등)

• ip-api

  특징: 상세한 위치 정보 제공 (국가, 지역, 도시, 우편번호, 위도/경도 등) 장점: 무료 버전 제공, 높은 정확도, HTTPS 지원(무료버전의 경우 미지원) 사용: RESTful API를 통해 다양한 프로그래밍 언어에서 사용 가능

프론트 엔드

자바 스크립트를 사용하여 사용자의 브라우저 타임존을 반환 받아 확인할 수 있다.

• Intl.DateTimeFormat 문서 참고

리뷰에서 텍스트 중간에 사진이 포함되었을 때 처리 방법

HTML 전체를 DB에 저장하는 방법은 리뷰가 아니라 단순하게 게시판의 게시글을 생각해서 생각했던 것이라 기획 의도에 맞지 않기도 하고 실제로 사용하기에도 부적절한 점(컬럼 타입을 'text' 혹은 'longtext'등으로 사용하여 HTML 전체를 저장하는 것은 성능에 영향이 분명히 있을 것)이 있을 것 같아 제외시켰습니다.

• 프론트 엔드 관점에서 생각해볼 수 있는 몇가지 사항
  • 이미지 로드 성능 : 이미지가 페이지 로딩 시점에서 올라오는 것이 아니라, 사용자가 스크롤 해서 이미지가 보일 때 로딩되도록 하는 방법을 생각해볼 수 있다. 또한 업로드 이미지가 너무 크지 않도록 제한을 주거나 최적화하여 불필요하게 큰 이미지가 업로드 되지 않도록 주의해야한다.
  • 에러 처리 : 이미지 로드가 실패하였을 때, 대체 이미지나 텍스트를 마련해놓는 것이 좋다.
  • 반응형 디자인 : 다양한 화면 크기에서 잘 보여줄 수 있도록 반응형 디자인을 적용하여 테스트 해보는 것을 생각해 볼 수 있다.