필자의 블로그는 필자마냥 이것저것 하긴 해야하는데 이걸 어떻게 사용해야 할지 이게 왜 이렇게 되는건지 모르고 막막한 사람들을 위한 블로그로 잡설+서론이 긴것은 양해바랍니다.
기존에 있던 서비스를 분석하고 어느정도 파악이 되어 기능을 추가하려고 손을 댔더니 데이터베이스 구조가 엉망이다...
관련 문서가 사실상 없는 상태와 마찬가지로 눈가리고 아웅식으로 운영이 되고 있던터라 이번 기회에 아예 새로운 프로젝트로 진행하여 Postgresql 과 Django를 이용해 새로 만들고자 했고 이를 위해 데이터베이스부터 다시 만들어보고자 했다
그런데 사수도 없고 인수인계도 제대로 받지 못했고 실력도 뛰어난것도 아닌 이 신입 개발자가 할 줄 아는게 뭐가 있겠는가? 모든 회사가 빠르게 서비스되야 하는 것을 요구하지만 다행히 지금 재직중인 곳은 상황을 이해해 주고 있고 현재 진행하려는 프로젝트는 중요성이 낮다 보니 느리더라도 유지보수가 용이하도록 재구성하고자 했다.
데이터베이스는 Postgresql이 상업적 사용에도 문제가 없고 기존 데이터베이스와 마찬가지로 관계형 데이터베이스이면서 SQL 기능 지원과 표준 지원을 준수하고 무엇보다 다양한 언어를 지원한다는 특장점이 있어 Postgresql로 선정하게 되었다.
이제 본론으로 들어가면 데이터베이스를 구축하는데 가장 중요한건? 바로 표준 가이드를 준수한 혹은 사내 가이드를 준수한 데이터베이스 네이밍 규칙이다.
자료 조사하면서 느낀건데 통칭 국룰이 없다... 자료들을 보면 서로 상반된 내용이 있는 경우가 있어 그냥 참고용으로만 보는게 좋을 것 같다.
데이터베이스 네이밍 규칙(Naming Conventions)
공통: 모든 식별자는 소문자 작성을 권장 -> 대문자 단어 중 예약어가 존재하기 때문, 복수형 배제 권장, 약어 사용시 공통 약어 사용 권장
- Schema(데이터베이스 구조)
- DB Alias와 동일하게 작성
- Shortname은 8자리를 넘기지 않고 고유한 이름 사용
- 예시) tourdb
- Table(테이블)
- 단어와 단어사이는 _로 구분
- 단어는 최대 8자리 까지 사용
- Table의 특성을 보여주는 단어 사용
- 예시) item_state, api_log
- Column(컬럼명)
- 의미 전달이 명확한 단어로 사용
- 테이블과 동일하게 단어사이는 _로 구분
- 일반적으로 약어의 조합으로 구성됨(해당 약어가 많이 이용되는 경우에만)
- 참고사항: primary key 컬럼을 id로만 하는 것은 비추천, 이후 해당 테이블의 id가 무슨 id인지 파악하기 어려움. 상품 id인지 유저 id인지 게시물 id인지 등등... 해당 id의 목적에 맞게 생성 권장함
- 순서규칙
- Primary Key 우선
- Not Null Columns 우선
- 길이 고정 컬럼(Date, Number, Char) 우선
- 짧은 컬럼 우선
- 동일한 규칙의 컬럼은 index 순서로 배치
최근 게시물이나 레퍼런스에서는 접두사/접미사(Prefixs, Suffixes)를 지양하고 있는 듯 하다. 옛날에는 많이 사용했던 규칙이지만 개체 이름에 개체 유형이 들어가면 안되므로 현재는 권장하지 않는 방법 중 하나이다.
예시) TB_USER, VW_FOOBAR 등
수 없이 많은 자료들을 보며 정리해보려 했지만 게시물마다 말이 다 다르고 어떤 게시물은 자기 모순적인 내용마저 들어있어 그나마 확실하면서 제일 빠르게 접하고 기본적인 세가지에 대해 작성하게 되었다.
아직도 모르는게 많아 서로 도움이 될 수 있도록 정보공유를 하며 서로가 배워가는 좋은 장소가 될 수 있길 바란다.
'기타 > What I Learned' 카테고리의 다른 글
[Flask] API 호출 방식과 오류 핸들링 (0) | 2024.02.06 |
---|---|
[Flask API] 기초 지식 (0) | 2024.02.05 |
[TIL] 자료구조 - 좌측/우측 회전 (0) | 2022.08.05 |
[TIL] 자료구조 - 좌측 회전 (0) | 2022.08.04 |
[TIL] 자료구조 - Rotate 메소드 (0) | 2022.08.03 |