인프런 - RDBMS Modeling 실습 1일차 (챕터 1, 2)

* 해당 학습은 다음 학습 이후의 단계 학습이다.

https://www.inflearn.com/course/%EA%B4%80%EA%B3%84%ED%98%95%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-rdbms/dashboard

RDBMS Modeling 기초 - 인프런 | 강의

* 해당 학습의 링크는 다음과 같다.

https://www.inflearn.com/course/%EB%94%94%EB%B9%84-rdbms-%EB%AA%A8%EB%8D%B8%EB%A7%81-%EC%8B%A4%EC%8A%B5/dashboard

RDBMS Modeling 실습 - 인프런 | 강의

 

1. 사용자(회사), 시도, 시군구 테이블 만들기

1. 데이터 베이스 모델링에서 Table View는 매우 중요하다.

2. 스토어 프로시저는 생각보다 잘 사용하지 않는다.

3. 사용자 테이블의 명칭은 Application에서 클래스, 변수 등의 명칭으로 상속되어 사용된다.
때문에 잘 작명하는게 중요하다.

   - 예시: 개발사 혹은 회사 특정 인원들만 아는 단어가 아닌, 일반, 대중적으로 사용되고 인식되는 단어와 표현 사용

Customer 관련

Database에서 ->
TB_Customer # 테이블
VW_Coustomer # 뷰테이블
SP_Coustomer_Add # 스토어프로시저
SP_Coustomer_Delete # 스토어프로시저

Application에서 ->
CustomerModel
CustomerRepository
CustomerHandler
btnSaveCustomer

4. 마스터 테이블

   - User, Profile 등 이름을 가지고 있는 테이블 자신을 가르켜 마스터 테이블이라 한다.

   - 마스터 테이블의 후보키 중 100% 유니크한 데이터가 없다면 더미키를 만들어 사용한다.

   - 후보키의 길이로 char, varchar를 키로 사용하는것 보다 int(32bit +/-  20억개)를 사용하는게 낫다.

      - 더 큰 용량의 int 타입도 있다.

      - 자동 증가를 사용하자 하지만 기준 테이블에서는 사용하지 않는게 좋다 (차후 설명)

5. 프라이머리 키의 중요성 (인덱스)

tb_user # 테이블명
Userid # 자동증가 pk 
UserName # 사용자 이름 varchar(50)

   - 위와 같은 키가 있을 때 다음을 수행한다고 가정한다.

select * from  tb_user
where username = 'xxx' 
# 위의 실행은 아래와 같다
where username like '%xxx%'

   - Scan : 키로 선언이 되어 있지 않고, 인덱스 처리가 되지 않은 컬럼에 대한 검색 조건은 상위에서 부터 단계별 전체 스캔을 하게 된다.

 

   - Search : 인덱스가 있다면, 데이터를 자동 정렬 해준다. 그리고 알고리즘에 의해 일정한 위치를 이동하며 검색을 한다. 

2. 시도 시군구 뷰 만들기

1. TB_User는 오해의 소지가 있기 때문에 TB_Company로 변경 후 수업 진행

2. 자신만의 네이밍 룰을 만들어 전체 설계에 유지하는게 중요하다

3. 복합속성은 단일 속성으로 분리해 줘라

   - 예시 :

서울시 마포구 상암동 112-12
충청북도 청주시 1읍 1면 1리 23-23

SD        SGGG     ETC
서울시    마포구   상암동

where sd = 1
groub by sd # 서울시와 관계된 항목만 가져와 사용

4. 주소에 아주 민감하지 않다면, 적정 수준으로 분리하는 과정을 가져야 한다.

5. TB_Company에 주소를 넣으면 정규식 1번을 위반하게 된다. 때문에 새로운 테이블로 분리해준다.

6. 메모리를 많이 정의해준다고 그만큼 미리 할당 되는 것이 아니라 사용하는 만큼만 쓴다. 너무 작게 설정하지 말자.

7. 최초, 프로토타입에는 꼭 필요한, 필수 정보만 넣고 나머지 정보는 차후에 정의하는게 좋다.

   - 필수 정보만을 가지고 pk, index, 정규식을 설계하고 차후 중요도가 낮은 정보들을 정의하면서 설계를 다시 거쳐 가는게 좋다.

8. 테이블이 pk로 서클처럼 연결되는 경우가 있다. 이러한 경우, 유니크한 key 생성에 문제가 될 수 있다. 데이터 열람이 가장 많은 중간 테이블에 하위 테이블 키를 참조시켜 복합키로 만들어 유니크하게 만들 수 있다.

   - 기존 서클처럼 pk 참조를 서로 하는 것이 잘못된 것은 아니다 다만, 조합된 키로 만들어지는 하나의 데이터를 특정 테이블이 참고 해야 한다면, 그룹 검색 등의 차후 작업을 위해서 고려해볼만한 방법이다.

9. 테이블 조인과 order by로 주소 만들기

10. 1 정규형으로 쪼갤 수 있을 만큼 최대한으로 쪼갠 테이블의 데이터들은 join을 사용해 하나의 테이블로 만들어 사용한다. 이것은 불필요한 중복 데이터를 없애기 위한 효율적인 방법이다.

   - 이것은 테이블 간의 부모와 자식간의 데이터 관계가 있을 때를 의미한다.

   - 데이터의 변경이 많지 않은 이와같은 테이블들은 뷰로 만들어 제공한다.

   - 모든 뷰 데이터는 결합된 데이터를 기반으로 원하는 데이터를 다시 추적할 필요가 있다 PK, FK를 다 넣어주자.

   - 아래와 같이 application에서 쉽게 사용할 수 있다.

11. 스토어 프로시저와  테이블 뷰간의 성능 이슈가 있다. 지금의 서버 장비로 이러한 차이는 그렇게 확연하게 차이가 날 정도가 아니다. 

  - 테이블 뷰는 요청이 왔을때 조인이 실행되어 데이터를 제공한다. 때문에 이미 최적화, 컴파일되어 서버에 올라간 스토어 프로시저보다 성능이 낮다고 평가받고 있다.

  * 개인적으로 테이블의 수, 데이터의 양, 전처리 등의 문제로 성능 이슈는 충분히 나올 수 있다고 생각된다. 하지만 일반적으로 테이블 뷰의 성능은 그렇게 차이가 나지 않을 것이라 생각도 된다.

  - 테이블 뷰보다 인덱싱이 더 중요하다.