프론트엔드/기타

[최종 프로젝트] 개발 세팅(1) - ERD 다이어그램 및 Supabase

장쫑이이 2024. 10. 22. 22:56

 

 

 

 

어느정도 1차적으로 기획단계가 마무리되어 가고 디자이너분들께서 와이어프레임 작업에 들어가셨다.

우리 조원들끼리도 이 시간을 활용하기 위해 먼저 유동적으로 프로그램 세팅을 시작하기로 했다.

 

 

먼저 개발 작업을 시작하기에 앞서 오늘 작업할 부분은 ERD 다이어그램 정리와 Supabase 기본 세팅!

 

 

ERD란?

ERD는 Entity Relationship Diagram(엔티티 관계 다이어그램)의 약자이다.
데이터베이스 설계 과정에서 사용되는 모델링 기법 중 하나 > 데이터 관계를 시각적으로 표현

- 데이터베이스 구조를 시각화할 수 있어 개발자와 설계자 간의 의사소통이 원활
- 데이터베이스 구조의 논리적 모순을 조기에 발견 가능

 

 

나중에 supabase에 추가할 DB 설계를 한눈에 보기 위해  ERD Cloud라는 웹 기반 프로그램을 사용하여 ERD 다이어그램을 만들기로 했다.

 

완벽하게 와이어프레임이 나오기 전이라,

데이터들이 어떤 방식으로 저장되고 표현될지 모르지만 간단하게 개발자들이 생각하는 관계성을 가지고 선 작업을 해놨다.

 

 

https://www.erdcloud.com/

 

ERDCloud

Draw ERD with your team members. All states are shared in real time. And it's FREE. Database modeling tool.

www.erdcloud.com

 

 

 

Supabase 세팅

두번째로는 supabase를 통해 위에서 작업한 ERD 다이어그램을 기준으로 데이터 세팅을 했다.

 

데이터베이스, 인증, 스토리지 등 애플리케이션 개발에 필요한 필수 백엔드 기능들을 제공, 이를 통해 서버 관리, 확장성, 보안 등의 부담을 크게 덜어낼 수 있어서 supabase를 사용

백엔드에서 신경써야할 복잡한 인프라 구축 및 관리 부담을 줄이고, 구현해야하는 핵심 로직에 집중하기 위함

 

 

`Table Editor`는 SQL 문법을 몰라도 쉽게 데이터베이스를 설정할 수 있는 장점이 있지만, SQL 문법을 조금 알면 더 복잡한 기능을 손쉽게 구현할 수 있다. 여기서는 기본 설정 시 꼭 확인해야 하는 부분과 권장 사항을 적어보려 한다.

 

1. RLS (Row-Level Security) 정책 추가하기

RLS 정책을 설정하지 않으면 테이블의 데이터 접근에 대한 제어가 불가능하여 보안에 취약할 수 있다.

각 테이블에 대한 접근 권한을 사용자별로 설정하여 데이터 보호를 강화하는 것이 좋다.

 

 

2. 외래키 작성하기

`외래키(Foreign Key)`는 테이블 간의 관계를 정의하는 데 중요한 요소이다. 외래키를 통해 테이블 간의 데이터 일관성을 유지하고, 무결성을 검증할 수 있다.

ALTER TABLE orders
ADD CONSTRAINT fk_user
FOREIGN KEY (user_id)
REFERENCES users(id);

 

 

3. 회원가입 Auth와 User_info 테이블 연결하기

회원가입 시스템을 설정할 때, Auth 테이블과 사용자 정보를 담고 있는 user_info 테이블을 연결하는 것이 좋다. 이를 통해 사용자 정보를 쉽게 조회하고 관리할 수 있.

ALTER TABLE user_info
ADD CONSTRAINT fk_auth_user
FOREIGN KEY (user_id)
REFERENCES auth(id);

 

 

4. Avatar를 사용하고 싶으면 스토리지를 설정

사용자의 프로필 사진(Avatar)을 저장하려면 별도의 스토리지 설정이 필요하다. 스토리지 설정을 통해 이미지 파일을 저장하고 관리할 수 있다. 예를 들어, 스토리지를 사용하여 이미지를 업로드하고 table에서 URL로 접근할 수 있도록 설정할 수 있다.

 

 

5. 데이터 타입 검증

PostgreSQL에서 선호하는 방식의 데이터 타입을 설정하는 것이 좋다. 예를 들어 varcher 보다는 text를, number 보다는 int4 등을 사용

 

 

6. 컬럼명에 대문자 사용하지 않기(snake_case 권장)

기본적으로 PostgreSQL의 경우 모든 식별자를 소문자로 자동 변환한다고 한다. 따라서 컬럼명을 대문자로 사용한 경우 나도모르게 오류를 유발할 수 있다. (아마 전의 프로젝트에서 그랬었던 기억이..)

 

처음에 작성할 때 큰따옴표로 작성하면 대문자로 표현이 가능하다고는 하지만 컬럼명에 접근할때마다 귀찮음이 발생 할 수 있다.

CREATE TABLE users (
    "UserName" VARCHAR(100)
);

SELECT "UserName" FROM users;  -- 매우 불편;;

 

그래서 일반적으로는 `snake_case` 방식의 네이밍 컨벤션을 추천하고 이번만큼은 우리도 해당 방식으로 진행하기로 했다.

 

 

 

내일은 GitHub 레포지토리를 생성하고 VSCode 환경 설정을 통해 전반적인 프로젝트 세팅을 마무리 할 예정이다.