초기 커밋

This commit is contained in:
hansoo
2025-03-26 18:16:46 +09:00
commit 266674cc0e
67 changed files with 14235 additions and 0 deletions

View File

@@ -0,0 +1,111 @@
# 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. 마이그레이션 스크립트 작성 및 테스트
```