RDBMS (관계형 데이터베이스 관리 시스템)
데이터를 테이블(관계) 형태로 조직화하여 관리하는 데이터베이스 관리 시스템
각 테이블은 행과 열로 구성되며, 데이터 간의 관계는 기본키와 외래키를 통해 정의
포트폴리오 매칭 시스템의 특성과 RDBMS 적용 이유
- 사용자 정보, 스킬 등 정형화된 데이터를 다룰 가능성이 높음
- 사용자와 포트폴리오 간의 다대다 관계를 처리해야 할 가능성이 있음
NoSQL 부적합 이유
- NoSQL은 테이블 간의 관계를 직접적으로 지원하지 않으므로, 사용자와 포트폴리오 간의 복잡한 매칭 로직을 구현하기 어렵다.
- 데이터 무결성과 일관성이 중요한 시스템에서 NoSQL은 추가적인 애플리케이션 로직을 필요로 하며, 복잡성이 증가한다.
- 시스템 초기 설계가 명확하고, 데이터 구조가 자주 변경되지 않는 경우에는 RDBMS의 고정된 스키마가 더 적합하기에..
VARCHAR, CHAR
VARCHAR
- 저장된 데이터의 길이만큼만 공간을 차지, 추가적으로 문자열 길이를 저장하기 위해 1~2바이트 더 사용
- 데이터 길이가 가변적인 경우 적합
CHAR
- char(50)이면 저장된 데이터가 50글자보다 짧으면, 나머지 공간은 공백으로 채워짐
- 데이터 길이가 고정되어 있어 데이터 검색이나 비교 작업에서 속도가 더 빠름
여기서 드는 의문은 항상 varchar을 사용하는 것이 합리적이지 않나..? 왜 나누어진거지
varchar은 저장하는 데이터의 길이를 추적해야하기 때문에, 각 데이터 항목에 추가적인 1~2바이트가 필요하고, char는 고정 길이이므로 길이를 추적할 필요가 없고, 데이터가 항상 같으 크기로 정렬되어 저장된다.
char은 고정된 길이 덕분에 검색과 비교가 더빠를 수 있고, 고정된 길이의 데이터가 많으면 디스크 I/O 작업에서 이점이 있을 수 있다고 함
varchar은 데이터 길이가 다를 경우, 데이터 정렬과 검색 작업 시 추가적인 계산이 필요할 수 있음
내가 varchar로 사용한 이유는 데이터 길이가 가변적이고, 짧은 데이터 이기에 ( 이름, 이메일 주소, 게시글 제목...)
ENUM?
소셜 로그인 제공자를 ENUM으로 한 이유
ENUM은 열거형 데이터 타입, 데이터베이스에서 특정 열에 대해 미리 정의된 값들 중 하나만 저장할 수 있도록 제한하는 데 사용
ENUM은 미리 정의된 값만 저장할 수 있고, ( 위에 내가 설정한 google, github로 설정하면 이 값만 )
내부적으로 ENUM값은 정수로 저장된다고함 (값은 정의 된 순서에 따라 저장)
=> 메모리를 절약할 수 있고, 비교 속도가 더 빠르다는 장점, 허용된 값 외의 데이터터는 삽입되지 않아서 데이터가 잘못 저장될 가능성이 줄어든다.
근데 다른 권한 레벨이나, 연차별 직책과 같은 것을 tinyint로 지정한건 확장성 때문에
그리고 enum을 사용하는 다른 이유는 데이터가 별도로 매핑 값을 확인안해도 됨
=> 이러한 생각으로 설정하였지만, 다른 분들하고 상의 해야할 듯..?
좋아요 테이블을 분리해야하는 이유는 좋아요 기능이 확장되지 않을까..?
좋아요 수에 기반해서 포트폴리오 랭킹 시스템 구현 가능할 것 같고, 사용자가 좋아요를 누른 포트폴리오를 내가 좋아요한 포트폴리오목록으로 별도로 조회 가능 -> 아 이건 따로 저장 버튼 만들기로 했던 것 같기도
, 좋아요 데이터를 분석해서 개인화 추천 시스템에 활용할 수 있지 않을까..? -> 유사한 기술 스택을 가진 포트폴리오 추천???
초기 ERD 작업
확인✔️
- 회원 관리
- 소셜로그인(google, github)과 로컬 로그인 모두 지원하도록 설계?
- 회원의 공통 정보를 부모 테이블로 분리하고, 일반 회원/사업자 정보를 자식 테이블로 관리?
- 포트폴리오 관리
- 포트폴리오 데이터를 Article 테이블로 관리?
- 좋아요 데이터를 별도의 테이블로 관리해서 확장 가능성을 높였는지?
- 기능 확장
- 사업자와 일반 회원의 데이터를 구분해서 권한별로 접근 제한이 가능하도록 설계?