# ZELLYY 서비스 데이터베이스 통합 계획

## 개요
이 문서는 ZELLYY Core와 각 서비스(적자 탈출 가계부, Subscription Manager, ZELLYY Card)의 데이터베이스 통합 방안을 설명합니다.

## 통합 원칙

1. **단일 Supabase 인스턴스** - 모든 서비스는 하나의 Supabase 인스턴스를 공유
2. **스키마 분리** - 서비스별로 독립된 스키마 사용
3. **공통 테이블 공유** - 사용자 정보 등 공통 데이터는 Core 스키마에서 관리
4. **Row-Level Security (RLS)** - 서비스별 데이터 접근 제어

## 스키마 구조

```
supabase
├── core        # ZELLYY Core 스키마
│   ├── users   # 사용자 정보
│   ├── services # 서비스 정보
│   └── service_access # 사용자-서비스 접근 권한
│
├── budget      # 적자 탈출 가계부 스키마
│   ├── accounts # 계좌 정보
│   ├── categories # 지출/수입 카테고리
│   ├── transactions # 거래 내역
│   └── budgets # 예산 계획
│
├── subscription # Subscription Manager 스키마
│   ├── subscriptions # 구독 정보
│   ├── payment_history # 결제 내역
│   └── reminders # 구독 알림 설정
│
└── card        # ZELLYY Card 스키마
    ├── cards   # 카드 정보
    ├── benefits # 카드 혜택
    └── usages  # 카드 사용 내역
```

## 데이터 관계 관리

### 외래 키 전략

각 서비스의 데이터는 `core.users` 테이블의 사용자 ID를 외래 키로 참조합니다:

```sql
-- 예: 적자 탈출 가계부의 계좌 테이블
CREATE TABLE budget.accounts (
  id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
  user_id UUID REFERENCES core.users(id) ON DELETE CASCADE,
  name TEXT NOT NULL,
  -- 기타 필드
);
```

### Row-Level Security (RLS) 정책

각 테이블에는 사용자별 접근 제어를 위한 RLS 정책을 적용합니다:

```sql
-- 예: 계좌 테이블의 RLS 정책
CREATE POLICY "사용자 본인의 계좌만 접근 가능" 
ON budget.accounts 
FOR ALL 
USING (auth.uid() = user_id);
```

## 데이터 마이그레이션 계획

기존 '적자 탈출 가계부'의 데이터베이스를 통합 스키마로 마이그레이션하는 단계:

1. **스키마 생성**: `budget` 스키마 생성
2. **테이블 이동**: 기존 테이블을 새 스키마로 이동
3. **외래 키 업데이트**: `core.users` 테이블을 참조하도록 외래 키 수정
4. **RLS 정책 적용**: 모든 테이블에 적절한 RLS 정책 설정
5. **데이터 검증**: 마이그레이션 후 데이터 무결성 확인

## 서비스별 데이터 접근

각 서비스는 자신의 스키마와 `core` 스키마에만 접근할 수 있도록 설계:

1. **서비스별 데이터베이스 역할 생성**
```sql
CREATE ROLE budget_service;
GRANT USAGE ON SCHEMA core TO budget_service;
GRANT USAGE ON SCHEMA budget TO budget_service;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA budget TO budget_service;
GRANT SELECT ON core.users TO budget_service;
```

2. **API 접근 제어**
   - 각 서비스별 API 키를 생성하여 적절한 권한 범위 설정
   - Core API를 통한 인증 및 권한 검증

## 성능 최적화

1. **인덱스 전략**
   - 사용자 ID 기반 인덱스 추가
   - 자주 조회되는 필드에 적절한 인덱스 설정

2. **캐싱 전략**
   - 사용자 세션 및 자주 사용되는 데이터 캐싱
   - 서비스별 캐시 무효화 정책 수립

## 다음 단계

1. 기존 '적자 탈출 가계부' 데이터베이스 스키마 상세 분석
2. 'Subscription Manager'와 'ZELLYY Card'의 요구사항 수집 및 스키마 설계
3. 공통 필드 및 관계 정의
4. 테스트 데이터베이스에서 통합 스키마 검증
5. 마이그레이션 스크립트 작성 및 테스트
```