숙박예약관리-04- DB 설계

=====================================================================================

 

***** 지극히 개인적인 생각입니다. *****
***** 이러한 방법 관점도 존재한다. 라는 생각으로 읽어주시면 감사하겠습니다. *****

 

최근 몇년간 프로젝트를 진행하면서 느낀점 어느순간 부터인가 모르겠지만

   발주자의 요구사항 분석
   해결대상 문제의 정의

   해결방법 정의

   정의된 해결방법을 S/W 로 구현

   이라는 어쩌면 가장 기본적이고 기초가 되는 부분을 생략하고
   화면부터 그리고 만드는 방식으로 진행하게 되는걸 당연시 하는 것 같다.
   
   그로인해
   S/W 개발이라는 업종에 종사하시는
   일부 PM, 기획자, 디자이너, 개발자, 발주처 담당자 등 종사자 분들이
   이러한 기본적인 부분에 대한 경험부족으로 인한 문제를 겪는듯하여
   가상의 프로젝트를 진행하여 프로젝트 진행의 한가지 방법에 대하여 보여드리고자 합니다.

   
   필요하신 분들에게 도움 되시길 바랍니다.

=====================================================================================

 

* DB 설계하는 여러가지 고급스럽고 어려운 내용의 글들이 많습니다.
   저는 어렵고 거창한 방법은 잘 모릅니다.
   그러나 제법 긴 시간동안 많은 프로젝트를 수행하는 과정에서 제가 정의한 방법을 공유하고자 합니다.

***** 은랑이의 DB 설계 Tip - 정답이 아닙니다. 수많은 방법중에 하나 입니다. *****

Tip.1. 최소한의 필수값 필드로 테이블을 정의 한다.

    예를 들어 관리자 정보관리 라는 말에서 관리해야 하는 정보 항목에는
    아이디, 비밀번호, 이름, 전자우편, 휴대전화 등등 많은 항목이 존재할 수 있다.
    그리고 추후 이러한 항목들은 추가될 수 있고 변경될 수 있다.
    => 아무리 많은 항목을 넣어도 결국 변경된다. 
    이러한 많은 정보를 취급하기 전에
    가장 기본적이고 필수적인 항목으로 테이블을 생성한다.
    ex) 관리자 정보를 저장할 테이블은 반드시 pk, 아이디, 비밀번호 필드가 존재한다.
           이외에 추가되는 필드는 DB 설계 이후 추후 정의하여 추가한다.

Tip.2. 테이블간의 레코드의 1:N 관계를 정의 하고 join 을 위한 외래키를 정의한다.
    ex) 1개의 객실은 N개의 예약에 선택될 수 있다.
           이 경우 객실과 예약은 1:N 의 관계가 성립한다.
           예약의 대상이 된 객실 정보의 연결을 위하여
           객실의 PK 값을 예약정보 저장 테이블에 저장하고
           외래키로 사용한다.

 

Tip.3. 위 Tip1 2 의 과정을 거치면 테이블 간의 관계와
          추후 데이타 조회를 위한 join 대상과 방법에 대한 정의가 이루어 진다.
          이렇게 뼈대가 구성된 이후 각 테이블이 필드를 추가하면 최소한의
          기본적인 DB 설계가 처리되는 것으로 볼 수 있다.

Tip.4. prefix 를 이용하여 가능한 필드명의 중복을 피하자.
          필드명 중복은 상관없다 alias 를 이용하여 해결할 수 있다고 많은 개발자들이 말한다.
          맞는 말이다.
          그러나
          미리 중복을 피하면 alias 설정 작업에 드는 시간과 노력을 절감할 수 있다.
          프로젝트 시간은 항상 부족하다. 시간은 있을때 아낄 수 있다.

          초기에 중복을 발생시키지 않으면 추후 * 이용한 Select 사용시 alias 설정 작업을 생략할 수 있는 경우가 매우 많다.

 

Tip.5. 필드명( 변수명도 마찬가지 )이 길어지는것을 두려워 하지 말자.
          필드명을 줄여서 뜻을 알기위해 코드를 더 뒤지는 것이 더 힘들다.
          필드명이 좀 길더라도 필드명 하나로 뜻을 필드값의 의미를 정확히 알 수 있으면 개발시간을 줄일 수 있다.

 

 

***** 설계된 DB ERD  예시 입니다.

 

2022.12.20 현재 기준