Model with options – 온더텍

Contents

관리자 전용 기능이나 잡다한 부가 기능들을 저장할 때는 데이터베이스 설계와 코드 유지보수성을 고려해야 합니다.
보통 다음과 같은 방식들이 있어요:

1. Boolean 컬럼 (On/Off 전용)

특정 기능이 단순히 켜짐/꺼짐 만 있으면 boolean 컬럼을 직접 추가하는 방식이 제일 직관적입니다.

예:

is_active      TINYINT(1) DEFAULT 1   -- 사용 정지 여부
is_visible     TINYINT(1) DEFAULT 1   -- 리스트/검색 노출 여부
is_featured    TINYINT(1) DEFAULT 0   -- 메인에 강조 여부

👉 장점: 쿼리 단순, 인덱싱 가능
👉 단점: 기능이 많아질수록 컬럼이 늘어나 DB 구조가 복잡해짐

2. JSON 컬럼 (MariaDB JSON 타입 또는 TEXT)

관리자 옵션이 많고 자주 변하는 경우 → JSON 컬럼에 묶어서 저장

예: admin_options JSON DEFAULT '{}'

데이터 예시:

{
  "is_visible": true,
  "is_suspended": false,
  "allow_booking": true,
  "highlight": false
}

👉 장점: 유연성 (필요할 때만 옵션 추가)
👉 단점: SQL 레벨에서 인덱스 걸기가 까다롭고, 조건 검색 속도가 느릴 수 있음

3. 별도 테이블 (옵션 테이블)

기능이 많고 확장성이 필요할 경우 key-value 저장 방식 테이블을 따로 둡니다.

예:

CREATE TABLE item_options (
  id INT AUTO_INCREMENT PRIMARY KEY,
  item_id INT NOT NULL,
  option_key VARCHAR(50),
  option_value VARCHAR(100),
  FOREIGN KEY (item_id) REFERENCES items(id)
);

데이터 예시:

| id | item\_id | option\_key   | option\_value |
| -- | -------- | ------------- | ------------- |
| 1  | 10       | is\_visible   | true          |
| 2  | 10       | is\_suspended | false         |

👉 장점: 확장 무제한, 다양한 기능 저장 가능
👉 단점: 조인 필요, 조회 성능 떨어질 수 있음

정리 (추천)

자주 쓰는 핵심 기능 (검색 노출 여부, 정지 여부 등) → 별도 Boolean 컬럼으로 분리
잡다한 부가 기능 (관리자만 쓰는 옵션, 실험적 기능 등) → JSON 컬럼으로 묶어서 관리
플러그인처럼 확장형 구조가 필요하면 별도 item_options 테이블 사용

👉 그러면 Flutter ItemModel에서는 Map<String, dynamic>? adminOptions 같은 필드를 두고 JSON을 그대로 주고받으면 깔끔합니다.

원하시나요? 제가 지금 ItemModel에 adminOptions (JSON) 필드 추가한 버전을 만들어드릴까요?

Post Views: 144