i18n을 위한 데이터베이스 설계 고민하기

i18n 데이터 설계

db → 서버 → 프론트 구조에서 데이터베이스에 있는 언어를 준비해야하기 때문에 언어 자체를 백엔드에서 정의해서 주는게 아니라 데이터베이스에서 번역이 되어 저장되야한다.

 

db 테이블을 title | enTitle | … 이렇게 확장하는게 옳은 방식인가 고민해보게 되었다.

 

데이터베이스의 언어 데이터값을 어떻게 관리할 수 있을까싶은 생각에 우리가 사용하는 프로젝트와 맞는 방식을 고민하게 되었다.

 

데이터베이스 저장 방식

열 기반 저장방식

 

가장 간단한 방법으로 각 언어에 대응하는 열을 추가하는 방식입니다.

장점

• 구현이 간단

단점

• 확장이 어렵다
  • 지원하는 언어가 늘어나거나 속성이 추가된다면 그에 대응하는 만큼 확장이 필요하므로 관리, 확장이 어렵다
• 스키마 업데이트가 필요하며 쿼리가 복잡해진다

 

 

JSON 기반 저장 방식

'{
	"en": 
		"Product Title in English", 
	"fr": 
		"Titre du Produit en Français", 
	"es": 
		"Título del Producto en Español"
}',

장점

• 열 수를 줄여 간단하고 확장을 위한 새로운 언어, 열을 추가하는 것도 쉽습니다.
• 단일 JSON 객체로 저장하게 되면 데이터의 크기도 작아 쿼리 시간이나 저장 비용이 절감될 수 있습니다.
• 특정 데이터베이스에서 JSONB 데이터 형식을 지원하여 검색 성능이 향상될 수 있습니다.

단점

• JSON 객체의 데이터를 색인, 검색하고자 하면 매우 느리고 복잡하여, 비효율적일 수 있습니다.
• 해당 데이터의 무결성과 일관성이 무시될 수 있습니다.
• 데이터를 변환하고 처리하는 것이 복잡할 수 있습니다.

 

테이블 기반 저장 방식

 

translation key 값으로 원본 텍스트 값을 나타낸다

즉 title 하나, description 하나 만들어 사용한다

1 | en | apple | apple
1 | en | red | red

장점

• 데이터 일관성과 무결성
  • 데이터베이스에서 지원하는 방식으로 데이터 유형과 제한 조건을 가질 수 있습니다
• 검색 및 색인을 위한 쿼리를 만들기 쉽습니다.
• 구조를 표현할 수 있어 모델링이나 RDBMS의 기능을 활용할 수 있습니다
• 인덱스 등의 성능을 향상시킬 수 있는 방식이 있습니다.

단점

• 구현이 어렵고 복잡합니다
• 데이터 중복성
  • 각 데이터에 대해 행이 만들어져 데이터 중복이 발생할 수 있어 저장 공간이 낭비될 수 있습니다.

 

정리

큰 규모의 프로젝트라면 데이터베이스의 기능을 활용할 수 있는 테이블 기반으로 만드는 것이 좋다. 다만 진행하는 프로젝트는 소규모이고 다국어를 필요로하는 데이터는 많지 않다고 생각된다. 따라서 정리하면 열의 수가 많지 않고 기존의 데이터 셋에서 확장할 이유도 크게 없다고 생각하여 처음 생각했던 열 기반 저장방식으로 구현해도 될거 같다고 생각한다

참고

Database Designs for Multilingual Apps

What are best practices for multi-language database design?